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EXECUTIVE  SUMMARY 


Modeling  and  simulation,  intelligent  software  agents,  and  other  technologies  can  support  network¬ 
centric  distributed  tracking.  These  technologies  came  together  in  the  Knowledge  Management  for 
Distributed  Tracking  (KMDT)  research  and  development  program  to  improve  naval  command, 
control,  and  decision  support.  The  program’s  approach  is  based  on  the  use  of  simulated  data  from 
sensor  and  motion  models,  intelligent  software  agents,  integrated  sensor  ontology,  and  a  line- 
of-bearing  cross-fix  algorithm. 

Modeling  and  simulation  was  used  to  generate  test  data  that  intelligent  agents  ingested  to  search 
for  information  that  could  help  localize  and  characterize  unknown  contacts  in  the  simulated  battle 
space.  In  these  simulations  using  a  hypothetical  scenario,  intelligent-software  agents  were  deployed 
over  a  simulated,  secure  Web-like  network  to  find  additional,  possibly  disparate,  sensor  data  from 
other  friendly  platforms  on  unknown  contacts. 

The  concept  of  operations  calls  for  the  agents  to  interact  with  the  integrated  sensor  ontology  to 
facilitate  distributed,  heterogeneous  sensor-data  fusion  and  to  reduce  uncertainty.  To  illustrate  these 
concepts,  a  simulation  is  described  that  generated  400  contact  reports  consisting  of  passive  lines  of 
bearing  that  were  fused  subsequently  by  intelligent  agents  to  localize  the  contacts,  thus  demonstrat¬ 
ing  the  potential  of  this  approach  to  reduce  information  overload  for  the  operator.  The  KMDT 
approach  demonstrates  how  knowledge  management  technologies  can  be  employed  to  improve 
situation  awareness  and  reduce  operator  workload. 
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1.  INTRODUCTION 


The  Knowledge  Management  of  Distributed  Tracking  (KMDT)  program  supports  the  concept  of 
network-centric  warfare  as  envisioned  in  FORCEnet  (Clark,  2002;  McGirr,  2001;  Ceruti  et  ah,  2004), 
which  is  the  U.S.  Navy’s  operational  construct  and  architectural  framework  for  naval  warfare  in  the 
information  age  (Clark,  2002).  To  accomplish  this  vision,  a  distributed  tracking  problem  was 
simulated  for  subsequent  demonstration  and  analysis  that  primarily  involves  the  localization  of 
targets  via  intersection  of  lines-of-bearing  (LOBs)  from  distributed  passive  sensors  (Ceruti  et  ah, 
2005).  Although  highly  simplified,  this  problem  may  reflect  current  political  and  operational 
strategies  that  restrict  usage  of  active  systems  for  environmental  and  security  reasons.  The 
simplification  is  intended  to  focus  the  demonstration  on  the  advantages  of  a  network-centric  concept 
of  operations  over  those  involving  legacy  stand-alone  architectures  and  systems. 

KMDT  focuses  on  technologies  that  are  essential  for  the  design  of  next-generation  tracking 
systems  that  use  knowledge  management  techniques  and  network-based  command  and  control 
to  reduce  uncertainty  in  command  decisions.  (See,  for  example,  Ceruti  and  Wright,  2005.)  These 
technologies  include  distributed  sensing,  modeling  and  simulation  (M&S)  (Ceruti  et  ah,  2005), 
intelligent  agents  (Ceruti,  2001;  Ceruti  &  Powers,  2004,  Deazeau  &  Muller,  1989),  and  ontology 
(Ceruti,  2004;  Ceruti  &  Wilcox,  2006;  Matheus  et  al.  2005;  Swanson  et  ah,  2007).  Distributed 
tracking  can  revolutionize  traditional  level-one  data  fusion  (e.g.,  detection,  localization,  tracking, 
classification,  and  identification)  (McGirr,  2001;  Ceruti  &  Wilcox,  2006;  Waltz  &  Elinas,  1990). 
Today,  the  Navy  does  not  use  the  majority  of  sensor  data  due  to  lack  of  correlation  opportunities. 
Through  knowledge  management  as  modeled  in  the  KMDT  simulation,  some  of  these  unused  sensor 
data  that  are  now  unavailable  can  be  quickly  fused  to  localize,  track,  and  classify  targets  of  interest 
(TOI),  which  will  result  in  a  future  reduction  in  uncertainty  in  command  centers. 

The  distributed  KMDT  architecture  enables  any  operator  connected  to  the  network  to 
deploy  intelligent  agents  to  retrieve  sensor  data  posted  to  common  repositories  at  ship  and 
shore-based  sensor-data  collection  stations.  The  network  does  not  contain  a  single  fusion  center 
where  all  fusion  processing  takes  place,  but  rather,  each  ship  or  shore-based  sensor  station  can 
perform  distributed  sensor-data  fusion  as  needed  to  meet  their  local  requirements.  The  agents 
retrieve  processed  sensor  data  at  the  message  level  and  are  not  connected  directly  to  the  remote 
sensors  themselves. 

KMDT’s  M&S  approach  uses  a  hypothetical  scenario  to  develop  and  evaluate  knowledge- 
management  techniques  (Ceruti  et  al.,  2005).  M&S  helps  to  conceptualize  the  salient  features  of  the 
battle  space  and  to  focus  on  characteristics  of  interest,  such  as  how  ships  move  in  the  water  and  how 
distributed  sensors  detect  them  in  a  controlled  environment  that  is  not  available  in  the  physical  world. 
It  also  allows  the  testing  of  many  hypothetical  scenarios  at  low  cost.  When  the  concepts  are  demon¬ 
strated  using  simulated  experiments,  these  results  serve  collectively  as  a  point  of  departure  for  more 
realistic  field  tests. 

Unlike  legacy  systems  that  rely  primarily  on  similar  sensor  types  to  detect,  localize,  and  track  TOI, 
new  approaches  also  can  use  dissimilar  sensor  types  for  level-one  data-fusion  tasks.  Our  previous 
research  was  oriented  towards  the  simulation  details  (Ceruti  et  al.,  2005)  and  the  integrated  sensor 
ontology  (Ceruti,  2004;  Ceruti  &  Wilcox,  2006;  Matheus  et  al.,  2005)  as  separate  components. 
However,  the  current  work  also  includes  agent  design,  the  agent-ontology  interaction,  and  a  database 
to  instantiate  some  of  the  concepts  in  the  integrated  sensor  ontology.  The  initial  KMDT  integrated 
sensor  ontology  was  based  on  ontology  components  developed  in  previous  projects,  as  explained  in 
Ceruti  (2004),  Ceruti  &  Wilcox  (2006),  and  Matheus  et  al.  (2005). 
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2.  MODELING  AND  SIMULATION 


This  section  describes  the  M&S  component  of  the  KMDT  program.  The  purpose  of  the  KMDT 
program  is  to  demonstrate  the  use  of  new  information  technologies  such  as  sensor  ontologies  and 
software  agents  in  a  secure,  distributed  network  for  level-one  data  fusion  (i.e.,  localization,  tracking, 
identification,  and  classification  of  targets)  in  the  maritime  battlespace.  It  is  anticipated  that  by  using 
these  information  technologies,  additional  information  normally  not  available  at  a  command  center 
can  be  quickly  fused  to  help  localize,  track,  and  classify  TOT  To  accomplish  this  task,  a  distributed 
tracking  problem  was  simulated  that  primarily  involves  the  localization  of  targets  via  intersection 
of  LOB  from  distributed  passive  sensors.  This  problem,  although  highly  simplified,  demonstrates  the 
advantages  of  exploiting  a  net-centric  concept  of  operations  over  those  involving  legacy  “stovepipe” 
architectures  and  systems.  The  KMDT  demonstration  concept  using  this  simulation  is  described  in 
Appendix  F. 

2.1  MODELING  AND  SIMULATION  DESIGN  OVERVIEW 

The  KMDT  simulation  represents  realistic  trial  scenarios  for  testing  technologies  and  concepts 
without  conducting  costly  field  experiments.  Additionally,  it  provides  an  analysis  tool  to  quantify 
results.  Figure  1  shows  a  functional  diagram  of  the  simulation.  The  simulation  contains  two  primary 
components:  a  scenario  specification  and  a  contact  generator.  The  scenario  consists  of  predefined 
fixed  or  mobile  sensor  systems  in  some  theater  of  operations,  with  specified  performance  capabili¬ 
ties.  Additionally,  the  scenario  contains  multiple  targets  with  specified  signal  emission  signatures, 
start  times,  and  initial  locations.  As  the  simulation  evolves  in  time,  the  positions  of  the  targets  and 
mobile  sensor  platforms  are  updated  at  discrete  time  steps  using  appropriate  motion  models.  Next, 
the  range  and  LOB  from  each  sensor  to  each  target  is  computed.  A  detection  model  then  determines 
the  probability  of  detection  computed  as  a  function  of  this  range.  Detection  alerts  are  subsequently 
declared  based  upon  the  probability  of  detection.  False  alarms  are  also  generated  according  to  accept¬ 
able  false  alarm  rates  for  each  sensor.  When  the  simulation  declares  a  detection  or  false  alarm,  the 
LOB  and  other  information  generated  by  the  simulation  are  posted  to  detection  databases  (Swanson 
et  ah,  2007). 


Figure  1.  KMDT  simulation  functional  diagram  (Ceruti  et  al.,  2005). 

2.2  THEATER  OF  OPERATIONS 

The  theater  of  operations  chosen  for  the  simulation  is  the  East  China  Sea  and  vicinity  (Figure  2). 
Not  only  is  this  an  area  of  interest  for  maritime  operations,  but  also  it  provides  a  variety  of  conditions 
to  test  robustly  the  technologies  being  developed  under  KMDT.  Both  shallow-water  littoral  and 
deep-water  environments  are  represented,  along  with  sea  access  via  straits  and  open  ocean.  Proximity 
of  both  mainland  and  islands  about  the  perimeter  of  the  East  China  Sea  provide  for  topographical 
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constraints  as  well  as  locations  for  land-based  sensor  sites,  air  and  sea  bases,  and  ports  of  opportunity 
for  maritime  vessels  and  aircraft  (Swanson  et  al.,  2007). 


Figure  2.  Scenario  theater  of  operations  (Swanson  et  al.,  2007). 


2.3  SCENARIO 

The  scenario  defines  the  targets  and  sensor  systems  for  a  simulation.  Different  scenarios  may  be 
designed  to  provide  testing  for  various  types  and  locations  of  targets  and  sensor  systems  in  different 
maritime  environments.  Sensor  and  target  attributes  and  initial  conditions  are  specified  via  scenario 
files.  Scenario  file  formats  are  documented  in  Appendix  B. 

2.3.1  Sensor  Systems 

The  simulation  can  represent  both  fixed  and  mobile  sensor  systems  (Swanson  et  al.,  2007).  Fixed 
sensor  systems  include  deep-water  arrays,  barrier  arrays,  and  land-based  systems;  mobile  sensor 
platforms  are  primarily  restricted  to  surface  vessels.*  Mobile  sensor  platforms  utilize  a  “waypoint” 
motion  model  described  in  Section  4.1.2.  The  simulation  currently  models  passive  acoustic  sensor 
systems  (e.g.,  the  SOund  Surveillance  System  [SOSUS]  and  the  Surveillance  Towed  Array  Surface 
System  [SURTASS])  only.^  Sensor  system  and  platform  attributes/initial  conditions 


*  Version  6  of  the  simulation  utilizes  a  two-dimensional  field  for  target  and  sensor  platform  motions,  and  thus  is  primarily  suited  for  surface 
vessels.  However,  it  may  be  used  for  submarines  and  aircraft  when  the  fidelity  of  the  simulation  does  not  require  precise  knowledge  of  the 
depth/altitude  of  the  vessel.  For  example,  with  simple  transmission  loss  models  that  do  not  require  knowledge  of  the  depth  of  the  target  or  sensor 
platform,  the  simulation  may  be  used  for  acoustic  detection  of  submarines  as  well  as  surface  vessels.  On  the  other  hand,  it  may  not  be  suitable  for 
airborne  sensors  whose  field  of  view  depends  on  the  altitude  of  the  aircraft.  Extensions  to  three-dimensional  fields  are  planned  for  future 
implementations. 

^  Electro-magnetic  (e.g.,  electronic  support  measures),  and  electro-optic  (e.g.,  infrared  and  video)  sensor  systems,  as  well  as  active  sensor 
systems,  are  planned  for  future  implementations.  Note  that  it  is  possible  to  emulate  non-acoustic  sensors  by  adjusting  source  levels,  array  gains, 
noise-level  specifications,  etc.,  to  give  appropriate  responses  for  such  sensors,  as  the  probability  of  detection  computation  is  independent  of  a 
given  source  type. 
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specified  via  the  scenario  file  include: 

•  Probability  of  false  alarm  deemed  acceptable  for  sensor  system 

•  Initial  platform  location  latitude  and  longitude 

•  Shipping  noise  level  offset  from  moderate  traffic  density  (at  initial  location) 

•  Sea-state  (at  initial  location) 

•  Array  gain  of  sensor  system 

•  Standard  deviation  for  LOB  error  distribution 

•  Maximum  detection  range  for  sensor  system  (azimuth-dependent) 

•  Waypoint  motion  model  track  leg  destination  latitude/longitude  and  speed 

2.3.2  Targets 

The  simulation  focuses  on  surface  targets,  although  submarine  and  air  targets  may  be  simulated 
with  restrictions.^  Targets  are  generally  classified  as  friendly  (F),  hostile  (H),  neutral  (N),  or 
unknown  (U),  and  contain  target-specific  signal  emission  signatures  that  can  be  used  for  more  refined 
identification.  The  signal  signatures  provide  the  source  levels  for  the  various  targets;  in  the  case 
of  acoustic  detection,  these  signatures  consist  of  sound  power  levels  at  discrete  frequencies  emitted 
by  the  target  vessel.  Targets  utilize  a  “quasi-random”  motion  model  described  in  Section  4.1.1.  This 
motion  model  is  designed  to  give  realistic  but  non-deterministic  behavior  to  targets,  thus  generating 
different  detection  statistics  for  separate  invocations  of  the  same  scenario.  Target  attributes/initial 
conditions  specified  via  the  scenario  file  include: 

•  Target  start  time 

•  Initial  target  location  latitude  and  longitude 

•  Initial  target  speed 

•  Standard  deviation  for  speed  distribution 

•  Maximum  target  speed 

•  Initial  target  heading 

•  Standard  deviation  for  heading  distribution 

•  Target  classification  (Friendly,  Hostile,  Neutral,  Unknown) 

•  Signal  emission  signature  (frequency  and  source  level  of  discrete  signal  components) 

2.4  CONTACT  GENERATOR 

A  contact  is  a  detection  of  a  target  by  a  sensor  based  on  a  computed  probability  of  detection  {Pd). 
The  contact  consists  primarily  of  an  LOB  from  the  sensor  to  the  target.  These  computations  are 
performed  in  the  simulation  by  a  Contact  Generator.  The  Contact  Generator  consists  of  time-stepped 
motion  models  for  updating  target  and  mobile  sensor  platform  positions,  geodetic  (great  circle) 
range,  and  LOB  computations  from  each  sensor  to  each  target,  and  detection  models  that  compute  the 
signal-to-noise  ratio  (SNR)  at  a  sensor  location  given  the  source  level  of  the  target,  transmission  loss 
between  target  and  sensor,  noise  level  at  the  sensor  location,  and  processing  gain  of  the  sensor 
system.  Based  on  the  computed  SNR  at  the  sensor,  the  Pd  is  computed  and  a  detection  decision  is 
made.  At  each  time-step,  a  false  alarm  may  also  be  generated  for  each  sensor.  Any  detections  or  false 
alarms  are  then  recorded  in  appropriate  detection  log  databases  for  subsequent  access  and  fusion  by 
KMDT  software  agents. 


^  See  footnote  1 . 
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2.4.1  Motion  Models 

Two  motion  models  are  provided  in  the  simulation,  a  “quasi-random”  model  to  represent  realistic 
tracks  of  unknown  targets,  and  a  deterministic  “waypoint”  model  to  represent  vessels  in  transit  lanes 
or  on  patrol. 

2.4.1. 1  Quasi-random  Motion  Modei 

The  quasi-random  model  provides  for  realistic,  non-deterministic  target  tracks  in  order  to  generate 
detection  statistics  from  multiple  invocations  of  a  given  scenario  that  will  accommodate  Monte 
Carlo-type  analyses.  At  each  time-step  of  the  simulation  the  model  projects  new  target  positions 
using  speeds  and  headings  that  are  randomly  selected  from  normal  distributions  whose  means  are 
respectively  given  by  the  previous  time-step  speed  and  heading,  and  whose  standard  deviations  are 
given  as  target  attributes  in  the  scenario  specification. 

Specification  of  smaller  (respectively  larger)  standard  deviations  result  in  smaller  (respectively 
larger)  speed  and  heading  changes  and  consequently  more  (respectively  less)  uniform  motion. 

The  model  also  employs  a  land-avoidance  algorithm  for  waterborne  vessels  that  adjusts  the  new 
target  position  if  the  randomly  selected  speed  and  heading  determine  a  location  over  land.  For  such 
a  location,  the  adjustment  is  accomplished  by  alternately  varying  the  heading  clockwise  and  counter¬ 
clockwise  in  increasing  increments  until  a  new  location  is  determined  that  is  over  the  sea. 

The  determination  of  whether  a  location  is  over  land  or  sea  is  made  by  specifying  a  closed  polygon 
that  encloses  the  sea  area.  This  polygon  consists  of  latitude-longitude  vertices,  later  converted 
to  rectangular  coordinates,  that  define  the  coastline;  islands  are  excluded  from  the  interior  of  the 
polygon  by  treating  them  as  enclaves,  that  is,  by  connecting  their  boundaries  to  that  of  the  exterior 
polygon  by  a  “doubly  traversed”  line. 

Thus,  by  traversing  the  exterior  polygon  in  the  clockwise  sense,  islands  will  be  traversed  in  the 
counter-clockwise  sense,  and  the  sea  will  always  be  on  the  right-hand  side  of  the  polygon  boundary. 
Then  the  number  of  times  the  polygon  boundary  intersects  the  line  parallel  to  the  y-axis  (i.e.,  the 
north-south  axis)  extending  below  (i.e.,  to  the  south  of)  the  location  in  question  will  be  odd  (respec¬ 
tively  even)  if  the  location  is  inside  (respectively  outside)  the  closed  polygon. 

2.4.1. 2  Waypoint  Motion  Modei 

The  waypoint  motion  model  provides  deterministic  tracks  to  be  used  by  targets  confined  to  transit 
lanes  or  sensor  platforms  on  patrol  (e.g.,  racetrack  or  picket  line  patrols)."^  Deterministic  tracks  for  a 
given  vessel  are  defined  by  track  segments  or  legs  specified  in  the  scenario.  A  track  leg  consists  of  a 
destination  location  (latitude  and  longitude)  and  a  leg  speed;  the  departure  location  is  assumed  to  be 
the  destination  location  of  the  preceding  leg. 

During  each  time-step  of  the  simulation,  the  current  track-leg  speed  and  heading,  as  determined 
from  the  rhumb  (constant  heading)  line  between  the  departure  and  destination  location,  are  used  to 
compute  a  new  platform  position;  if  the  range  to  this  position  exceeds  that  to  the  destination  location 
of  the  current  leg,  the  current  course  is  followed  to  the  waypoint  location,  the  time  of  arrival  at  the 
waypoint  is  computed,  and  the  new  course  is  followed  for  the  remaining  time  in  the  time-step. 


^  In  Version  6  of  the  simulation,  the  waypoint  motion  model  is  used  only  by  sensor  platforms,  while  the  quasi¬ 
random  model  is  used  only  by  targets. 
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2.4.2  Detection  Models 

Targets  are  detected  by  sensors  via  computation  of  a  range-dependent  probability  of  detection,  Pd. 
At  each  time-step  of  the  simulation,  the  geodetic  (great  circle)  range  and  LOB  from  each  sensor  to 
each  target  in  the  field  is  computed.  For  those  targets  that  are  closer  to  the  sensor  than  the  maximum 
detection  range  for  that  sensor  along  the  computed  LOB  azimuth  (as  specified  in  the  scenario),  the 
SNR  is  computed.  For  passive  systems,  the  SNR  is  generally  a  function  of  the  source  level  of  the 
target,  the  transmission  loss  between  the  target  and  sensor,  the  noise  level  at  the  sensor,  and  any  pro¬ 
cessing  gain  of  the  sensor  system. 

Since  these  SNR  components  are  generally  functions  of  the  frequency,  a  separate  computation 
must  be  made  for  each  frequency  component  of  the  target  signal  signature.  Since  the  transmission 
loss  is  a  function  of  the  range  from  the  target  to  sensor,  the  SNR  is  also  range-dependent.  Subse¬ 
quently,  the  Pd  is  computed  from  the  SNR.^  A  detection  alert  is  declared  when  a  random  number 
selected  from  a  uniform  distribution  between  0  and  1  is  less  than  the  computed  Pd. 

Note  that  only  some  of  the  frequency  components  of  a  target  signal  signature  may  be  detected 
at  any  given  time.  At  each  time-step,  a  false  alarm  is  also  generated  for  each  sensor  when  a  random 
number  selected  from  a  uniform  distribution  between  0  and  1  is  less  than  the  sensor’s  specified 
probability  of  false  alarm,  Pfa-  Detection  alerts  and  false  alarms  are  reported  to  individual  detection 
logs  for  each  sensor,  as  well  as  a  composite  log  for  all  sensors. 

2.4. 2.1  Passive  Acoustic  Sensors 

For  passive  acoustic  sensors,  the  SNR  is  modeled  by  the  passive  “SONAR  equation.”  In  units  of 
decibels,  the  SONAR  equation  is 

DT  =  SL-TL  +  AG-AN, 

where 

DT  =  Detection  Threshold,  the  SNR  necessary  to  achieve  a  desired  level  of  performance 
(DT  is  also  called  the  Recognition  Differential,  RD); 

SL  =  Source  Level,  the  ratio  of  the  acoustic  intensity  (proportional  to  the  squared  pressure)  of 
the  source  to  that  of  a  plane  wave  of  rms  pressure  pa=  \  pPa  at  a  reference  distance 
ro  =  1  m  from  the  source; 

TL  =  Transmission  Loss,  the  ratio  of  the  acoustic  intensity  at  a  distance  ro  =  1  m  from  the 
source  to  that  at  a  distance  r  from  the  source; 

AG  =  Array  Gain,  the  ratio  of  the  SNR  of  an  array  of  coherently  summed  receiver  elements 
to  that  of  a  single  element; 

AN  =  Ambient  Noise,  the  spectrum  level  (power)  of  all  incoherent  sources  of  noise  in  a  1  Hz 
band  at  the  receiver. 

Thus,  for  a  given  SL,  TL,  AG,  and  AN,  the  passive  SONAR  equation  may  be  evaluated  for  the  DT 
that  represents  the  SNR.  The  Pd  is  computed  as  a  function  of  the  DT  and  a  specified  Pfa  (see  Appen¬ 
dix  E).  Note  that  there  are  various  representations  for  these  terms  with  different  levels  of  fidelity. 

For  example,  in  a  homogeneous  acoustic  environment,  TL  may  be  modeled  by  simple  spreading 
loss  and  absorption.  However,  boundaries  and  spatial  and  temporal  variability  of  the  sound  field 
can  cause  refraction  and  other  effects  requiring  sophisticated  computer  models  and  environmental 
databases  for  evaluation.  For  the  purposes  of  the  KMDT  simulation,  only  low-fidelity  models  are 
generally  required.  The  TL  and  AN  models  incorporated  in  the  simulation  are  described  in  the 


^  Detection  theory,  including  the  computation  of  the  Pd,  is  reviewed  in  Appendix  E. 
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following  subsections;  SL  for  the  targets  and  AG  for  the  sensors  are  specified  via  the  scenario 
specifications. 

2.4. 2. 1.1  Transmission  Loss  Modei 

In  homogeneous  seawater,  the  TL  results  from  geometric  spreading  and  absorption  of  acoustic 
energy,  and  may  be  modeled  by 

TL  =  20  log  r+ar,  r<rt; 

=  10  log  r^+ 10  log  r  +  «r,  r>rt. 

This  represents  a  combination  of  spherical  spreading  near  the  source,  and  cylindrical  spreading 
away  from  the  source  due  to  the  confinement  of  the  propagation  to  a  horizontal  layer  between  the 
atmosphere  and  ocean  basin.  Here,  r  is  the  horizontal  distance  from  the  source  to  the  receiver,  r,  is 
the  horizontal  distance  from  the  source  to  the  transition  from  spherical  to  cylindrical  spreading,  and  a 
is  an  absorption  coefficient. 

The  transition  range  n  is  computed  as  follows:  Suppose  a  homogeneous  ocean  (i.e.,  where  the 
sound  speed  c  =  ci  is  constant)  is  confined  to  a  layer  of  depth  h  as  shown  in  Figure  3.  For  a  point 
source,  waves  will  propagate  outward  in  spherical  wavefronts  (i.e.,  surfaces  of  constant  phase), 
whose  rays  (i.e.,  directions  of  wave  propagation  perpendicular  to  the  wavefronts)  are  straight.  When 
the  waves  reach  the  ocean  boundaries,  they  will  reflect  from  and/or  transmit  through  the  boundaries. 
Due  to  the  large  acoustic  impedance  difference  between  the  seawater  and  air,  waves  will  be  almost 
totally  reflected  at  the  surface  for  any  grazing  angle  i9  between  a  ray  and  the  horizontal  boundary. 

At  the  ocean  bottom,  however,  the  acoustic  impedance  difference  is  usually  less,  so  that  the  wave 
is  both  reflected  and  transmitted.  For  the  reflected  wave,  the  angle  of  reflection  equals  the  angle  of 
incidence  i9i;  however,  for  the  transmitted  wave,  the  angle  of  transmission  <5*2  is  related  to  the  angle 
of  incidence  i9i  by  the  ratio  of  the  sound  speeds  in  the  adjacent  layers.  This  relationship  is  expressed 
by  Snell’s  Law, 

cosi9j  _  cos  (92 

Cj  C2 

where  C2  is  the  sound  speed  in  the  bottom  substrate.  If  C2  =  A:  ci  >  ci,  as  is  typically  the  case  in  ocean 
environments,  then  there  will  be  an  incident  angle  i9i  where  the  angle  of  transmission  32  =  0,  that  is, 
i9i  =  cos"'(ci/  C2)  =  cos"'(l/  k).  This  angle  is  called  the  critical  angle  3c.  For  incident  angles  i9i  <  3c, 
there  is  no  transmitted  wave,  and  propagation  is  trapped  in  the  layer.  Now,  for  a  source  located  at 
depth  z  =  zo,  tan  3c  =  {h-ZQ)/rc,  where  the  horizontal  range  to  where  the  ray  with  critical  angle  3c 
reaches  the  bottom.  Let  this  range  be  the  transition  range  between  spherical  and  cylindrical  spread¬ 
ing. 

Then, 

^ 

‘  tan[cos^'  (1/  k)] 

Typically,  A: «  5  for  sound  speeds  in  seawater  and  bottom  substrates  consisting  of  elastic  solids. 
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Figure  3.  Transmission  loss  model  geometry. 


The  absorption  coefficient  a  is  given  by  the  following  expression  (Thorp,  1967): 


a  =  0.0010936133 


0.1/"  40/" 

1  +  /"  ^4100  +  /' 


+  0.000275/" 


dB/m, 


where /is  the  frequency  in  kHz,  which  represents  the  transmission  loss  per  unit  length  due  to  viscous 
and  chemical  relaxation  processes. 

2. 4. 2. 1.2  Ambient  Noise  Modei 

Acoustic  AN  is  defined  as  the  power  level  at  the  receiver  of  all  incoherent  sources  of  noise  in  a 
1-Hz  band  about  a  specified  frequency;  that  is,  as  10  logio(AO,  where  N  is  the  noise  spectrum  level 
relative  to  a  1  -Hz  frequency  band.  The  AN  as  a  function  of  frequency  is  modeled  by  fitting  curves 
to  typical  deep-water  noise  spectra.  The  noise  is  caused  primarily  by  ocean  turbulence,  shipping, 
wind/sea  state,  and  thermal  agitation.  The  family  of  spectra  for  different  shipping  densities  and 
wind/sea  states  are  shown  in  Figure  4.  Shipping  offset  levels  and  wind/sea  states  for  individual 
sensor  locations  are  specified  via  the  scenario  file  (see  Appendix  B). 


Figure  4.  AN  level  vs.  frequency. 
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2.5  DETECTION  DATABASES 

The  detection  databases  represent  repositories  (logs)  for  all  target  detections  and  false  alarms 
generated  by  the  simulation.  In  the  KMDT  concept  of  operations,  these  databases  represent  Web 
services  supplied  by  distributed  sensor  systems  connected  to  a  network  that  can  be  searched  by 
agents  to  discover  information  for  subsequent  fusion.  The  databases  consist  of  individual  ASCII  files 
for  each  sensor,  and  a  composite  file  containing  detections  and  false  alarms  from  all  sensors  in  the 
scenario.  Each  file  record  consists  of  a  single  detection  alert  (that  may  be  a  false  alarm),  with  the 
following  parameters: 

•  Sensor/platform  identification 

•  Time  of  the  alert/false  alarm,  including  any  signal  propagation  time  from  the  target  to  the 
sensor 

•  Sensor  location  latitude  and  longitude 

•  Approximate  LOB  from  the  sensor  to  the  target 

•  Frequencies  of  detected  signal  components 

•  Maximum  detection  range  along  the  reported  LOB  for  the  sensor  (as  specified  in  the 
scenario) 

In  addition  to  the  above  parameters,  the  following  information  extracted  from  the  simulation 
is  appended  to  the  detection  alert  record  for  validation  purposes.  This  information,  of  course,  would 
not  be  available  to  an  operational  system. 

•  The  ground  truth  location  latitude  and  longitude  of  the  target 

•  The  classification  of  the  target  (friendly,  hostile,  neutral,  unknown) 

Formats  for  the  detection  log  records  are  documented  in  Appendix  C. 
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3.  INTELLIGENT  SOFTWARE  AGENTS 


Current  intelligence,  surveillance,  reconnaissance  (ISR)  capabilities  of  naval  strike  groups  have 
a  shortfall  in  sensor  tasking  and  data  exploitation.  Tactical  commanders  must  be  able  to  recognize 
blind  spots  in  their  tactical  picture  so  they  can  obtain  specific  information  to  reduce  their  uncertainty. 
The  Navy  does  not  have  the  capacity  to  use  all  the  data  it  collects  from  its  own  sensors.  Moreover, 
tactical  commanders  and  their  staffs  lack  the  resources  and  the  tools  to  examine  and  consider  using 
all  the  available  information  not  only  from  naval  sensors,  but  also  from  national  ISR  systems.  ISR 
systems  provide  large  quantities  of  information  from  a  wide  range  of  national,  theater,  and  organic 
sensors.  However,  the  Navy  does  not  own  all  the  sensors  it  wants  to  access.  Various  other  organiza¬ 
tions  manage  many  sensors  that  the  Navy  needs. 

The  insights  and  potential  advantages  of  this  information  often  are  not  used  at  the  tactical  level 
because  of  the  difficulties  for  tactical  commanders  to  task  sensors,  analyze  the  information,  evaluate 
its  relevance,  and  then  exploit  it  in  time  to  be  effective.  Today,  this  event  cycle,  including  the  time 
required  for  sensors  to  respond  to  a  commander’s  tasking,  is  usually  too  long  for  the  results  to  be 
used  tactically.  The  information  would  be  overtaken  by  events  by  the  time  it  arrived.  Even  if  the 
information  arrived  in  time,  few  tools  are  available  to  help  exploit  it. 

Naval  strike  groups  are  spread  more  widely  over  the  globe  and  now  rely  more  frequently  on  reach 
back  to  help  cope  with  the  flood  of  information  available  from  ISR  systems.  The  functionality  that 
the  KMDT  agents  can  provide  is  a  natural  starting  point  from  which  to  utilize  the  new  capabilities 
and  better  facilitate  reach-back. 

3.1.  AGENT  DESIGN  AND  USE 

This  section  describes  the  design  and  use  of  the  intelligent-software  agents.  All  KMDT  agents 
are  designed  as  threaded  programs.  KMDT  agents  are  constructed  from  a  set  of  top-level  Java® 
classes.  The  design  is  agent-centric  in  the  sense  that  capabilities  are  composed  of  loosely  coupled 
agents  that  are  adapted  to  a  specific  purpose.  This  adaptability  means  that  new  capabilities  likewise 
are  composed  of  loosely  coupled  agents  that  are  added  into  the  general  framework  as  they  are 
developed.  KMDT  has  developed  mostly  data-integration  agents  that  retrieve,  translate,  analyze, 
and  combine  data  from  networked  data  sources  with  different  data  representations.  Transformation 
and  integration  of  relevant  tracking  data,  non-spatial  data,  and  spatial  data  add  value.  Support  agents 
using  data-staging  structure  like  high-speed  cache  memory  facilitate  these  processes. 

The  KMDT  agent  classes  were  developed  and  tested  on  previous  projects.  Support  classes  also 
have  been  developed  and  used  successfully  on  past  projects.  Both  the  agent  and  support  classes  are 
extensible.  Their  extensible  framework  will  allow  more  functionality  to  be  added  incrementally  over 
the  life  of  the  KMDT  project.  KMDT  agents  communicate  over  TCP/IP.  Agent  communication  code 
rarely  is  reused  project  to  project.  One  reason  is  that  the  experimental  nature  of  the  code  itself  usually 
means  that  it  is  more  efficient  to  develop  code  “from  scratch”  than  to  customize  code  from  another 
project.  Another  reason  is  that  agent  communication  in  general  has  become  increasingly  more 
complex  to  implement  over  time. 

We  use  the  Java®  event  model  and  sockets  for  most  agent  communication.  Before  the  time  of 
firewalls,  e-mail  worms,  Web  services,  extensible  Markup  Language  (XML),  and  Simple  Object 
Access  Protocol  (SOAP),  agent  communication  was  more  straightforward  to  implement.  Socket 
connections  were  made  between  agents  and  data  were  exchanged.  Communicating  via  TCP/IP  means 
having  to  resolve  how  agents  connect  to  each  other,  authenticate  themselves,  encode  and  decode 
XML  messages,  receive  messages,  and  report  errors. 
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Each  type  of  agent  is  assigned  a  specific  high-level  task.  KMDT  features  the  following  types  of 
agents. 

•  The  Timer  Agent  is  like  a  stopwatch  or  an  alarm  clock.  It  enables  the  autonomous  behavior 
of  an  agent  through  timed  method  calls.  It  is  installed  as  part  of  the  KMDT  package. 

•  The  Monitoring  Agent  is  the  base  class  of  the  File  Agent.  The  Monitoring  Agent  can  alert 
the  user  or  another  agent  whenever  a  file  is  updated,  whenever  the  size  of  a  file  changes,  or 
whenever  a  file  is  deleted.  The  Monitoring  Agent  can  perform  one  of  four  actions  when  it 
detects  a  change.  The  Monitoring  Agent  can  display  an  alert,  execute  a  shell  command,  start 
an  application,  or  notify  another  agent  about  the  change. 

•  The  File  Agent  sends  recently  collected  sensor  LOB  data  from  the  M&S  simulation  to  the 
Transfer-Data-to-Database  Agent,  which  sometimes  is  called  the  “Database-Interface 
Agent.” 

•  The  Data-to-Database  Agent  accepts  the  simulated  LOB  detection  data  as  comma-separated 
values  from  the  File  Agent  over  a  socket.  Then  it  creates  the  tables  and  stores  the  detection- 
log  data  in  a  detection  database  using  Microsoft  Access.  The  Data-to-Database  Agent 
calculates  the  end-point  latitude  and  longitude  for  each  LOB  entry  and  stores  the  information 
in  the  database.  The  Transfer-Data-to-Database  Agent  is  the  base  class  of  the  Data-to- 
Database  Agent. 

•  The  Cross-Fix  Display  Agent  accesses  the  detection-log  data  directly  from  the  detection 
database,  downloads  the  data  into  local  memory,  and  transforms  each  LOB  from  a  location 
into  a  vector.  Then  it  examines  other  detections  for  possible  a  LOB  cross-fix.  The  Cross-Fix 
Display  Agent  attempts  to  associate  each  validated  LOB  with  a  crossing  LOB  from  the 
detection-log  database,  sometimes  called  the  “contact  database.” 

•  The  Temporal-Proximity  Agent  screens  out  cross-fixes  with  time  signatures  that  do  not  fall 
within  a  specified  time  interval  of  each  other.  This  agent  can  display  its  output  in  a  Microsoft 
Excel®  spreadsheet. 

•  The  user  can  select  an  option  to  trigger  an  alert-type  notification  to  the  user  when  new  data 
are  received.  The  Alarm  Agent  issues  this  alert  to  the  user  interface. 

•  The  URL  Reader  Agent  reads  the  text  of  Web  pages  and  forwards  the  text  to  any  other 
agent  that  is  listening. 

•  The  Filter  Agent  scores  information  using  a  keyword  list,  a  Kohonen  neural  network,  and 
maintains  a  user  profile. 

•  The  Agent-Control  Interface  enables  the  user  to  create  and  deploy  various  intelligent 
agents. 

A  typical  sequence  of  events  for  agent  use  is  as  follows. 

1 .  As  described  above,  the  M&S  program  generates  a  detection  log  every  time  the  program  is 
executed. 

2.  The  operator  creates  and  deploys  the  File-Monitor  Agent  with  the  user-friendly  KMDT 
interface. 

3.  The  File-Monitor  Agent  detects  the  presence  of  updated  data  in  the  detection  log  and  issues 
an  alert  to  the  operator. 

4.  The  operator  creates  and  deploys  the  Data-to-Database  Agent  with  the  user-friendly  KMDT 
interface. 

5.  The  Data-to-Database  agent  ingests  the  detection-log  data  and  calculates  the  end  point 
latitude  and  longitude  for  each  entry. 

6.  The  Data-to-Database  agent  stores  the  data  in  a  Microsoft  Access  database. 
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7.  The  operator  creates  and  deploys  the  Cross-Fix  Display  Agent  with  the  user-friendly  KMDT 
interface. 

8.  The  Cross-Fix  Display  Agent  establishes  a  connection  with  the  database  and  downloads  the 
data  into  local  memory. 

9.  The  Cross-Fix  Display  Agent  finds  all  of  the  LOBs  that  cross  each  other,  regardless  of  timing 
and  regardless  of  LOB  validity  with  respect  to  false  alarms. 

10.  The  operator  creates  and  deploys  the  Temporal-Feasibility  Agent  with  the  user-friendly 
KMDT  interface. 

11.  The  Temporal-Feasibility  Agent  searches  the  cross-fixes  to  determine  which  ones  occurred 
within  the  specified  time  of  each  other.  This  window  is  typically  a  half  an  hour. 

12.  The  results  of  the  computations  completed  by  the  Cross-Fix  Display  Agent  and  the 
Temporal-Feasibility  Agent  are  displayed  on  the  screen. 

3.2  AGENT-CONTROL  INTERFACE  AND  AGENT  FUNCTIONS 

Figures  5  through  17  show  examples  of  the  user- interface  screens  and  results  of  the  intelligent- 
software  agents  described  in  the  last  section.  The  example  shown  in  Figures  15  and  16  is  like  the  one 
in  Figures  1 1  and  12,  except  that  Figures  15  and  16  illustrate  the  option  to  display  only  the  cross¬ 
fixes  as  small  circles,  and  not  as  intersections  of  LOBs.  This  option  helps  reduce  screen  clutter. 

In  some  figures,  two  concentric  circles  around  each  sensor  location  signify  a  variable  detection  range 
where  obstacles,  such  as  islands,  limit  the  range  over  some  angles,  but  are  not  an  obstruction  at  other 
angles.  The  specific  angles  are  coded  accurately  in  the  sensor-specification  file  of  the  modeling  and 
simulation  program,  but  the  exact  shape  of  the  detection  area  is  not  shown  on  the  display. 


Start  I  I  ^Inbox-...|  ^9Int...  --I  ^3Mtcr,,.--[  >^2Win,,,’>|  0Priinals...  |  M  CijWlN...  ||,^3  3av...  ,  KMDTL,,,  | 


Figure  5.  Top-level  operator’s  interface  for  creating  and  controlling  the  agents.  This  screen  shows 
that  the  Cross-Fix  Display  Agent  has  finished  executing. 
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Figure  6.  File-Monitor  Agent  input  control  screen. 
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Figure  7.  File-Monitor  Agent  results  display. 
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Figure  8.  Data-to-Database  Agent  input  control  screen. 


,  R  Data  to  PB  Agent .  .  .  .  .  .  .  .  .  . .  .  .  .  .  .  o*^  p*^  B 

File  Edit 


insert  into  Contacts?  valuesCAPFt  1  '.’54. 00', '28. 00'. '1 32.00', '1  41 .0'.'t  20'. '1 49', 'O', 'O', 'O’, 'O'. 'O'. 'O', 'O', 'O', '1 50', ‘26.1 3'.'1 33.77', 'U;:> 

after  insert  into  Contacts?  vaiues('APF1 1  ',‘54. 00'. '28. 00', '1 32.00'.'1 41 .0',1  20’, '1  49'. 'O'. 'O'. 'O', 'O', 'O', 'O', 'O'. 'O'. '1 50'. '26.1 3','1 33.77'.'U;') 

insert  into  Contacts?  valuesCAPF05'.’55.50','33.00'.'1 29.00','282.2'.'62'.'0'.'0','0','0‘,'0’.'0'.'0'.'0'.'0'.'50','0','0',rA;') 

arter  insert  into  Contacts?  vaiues('APF05',‘55.50'.‘33.00','1 29.00'.’282.2','62','0’.'0'.'0'.'0'.'0‘,'0','0','0','0’,’50'.'0'.’0',’FA;') 

insert  into  Contacts?  valuesCAPF1 1  '.'58.50', '28. OO'.'1 32.00',‘356.6'.'884'.'0','0',‘0',‘0',‘0'.'0'.'0'.'0'.'0','75','0','0','FA;') 

arter  insert  into  Contacts?  vaiues('APF1 1  ','5e.50'.'28.00‘,'1 32.00'. '356.6', '884'. 'O'. 'O'. ‘O'. 'O'. 'O', 'O', 'O', 'O'.  13'. '75'. ‘O'. 'O'. 'FA;*) 

insert  into  Contacts?  values('APF04',’60.00','33.50'.'1 29.00', ‘1  70. 5'. '835‘, 'O', 'O', 'O', ‘O', ‘O’, 'O'. ‘O'. 'O', 'O', '50', 'O', 'O', 'FA;) 

arter  insert  into  Contacts?  vaiues('APF04‘,«0. 00'. '33.50', '1 29.00'.’1 70.5', '835', 'O'. 'O'. 'O'. 'O'. 'O', 'O', 'O', 'O', 'O'. '50'. 'O'. 'O'. 'FA;) 

insert  into  Contacts?  values(’APF02'. '62.50', '34.00'.'1 28.50',1 73.0'.'709’,'0','0','0','0','0'.'0'.'0'.'0','0‘,'50','0',1D','FA;) 

arter  insert  into  Contacts?  vaiues('APFO?','62.50'.‘34.00','1 2e.50'.'1 73.0','709'.'0'.'0'.'0'.'0'.'0','0','0','0'.'0'.'50'.'0'.'0'.'FA;) 

insert  into  Contacts?  valuesCAPFI  0'.'63.00','?7.00'.'1 31 .00', '237.1  '.'80'.'0'.'0','0','0',1D','0'.'0'.'0'.'0'.'1 50', 'O', 'O', 'FA;) 

arter  insert  into  Contacts?  vaiues('APF1 0','63.00'.'27.00','1 31 .00'.'237.1  ','80','0','0'.‘0'.‘0'.'0'.'0','0','0','0'.'1 50'.'0'.'0'.'FA;) 

insert  into  Contacts?  values('APF06'. ’66.00', '27.00', '1 27.00', '232. O'. '385', 'O', 'O', 'O', 'O', 'O’. 'O'. ‘O'. 'O'. 'O'.'l  00', 'O'. t)’. 'FA;) 

arter  insert  into  Contacts?  vaiues('APF06‘,'66.00'.'27.00','1 27. 00'. '232. O', '385', 'O'. 'O'. 'O'. 'O'. 'O', 'O', 'O', 'O', “O'.'l  00'. 'O'. 'O', 'FA;) 

insert  into  Contacts?  valuesCAPF04','67.50','33.50'.'1 29.00','1 07.5'.‘97'.'0','0'.'0','0',’0'.'0'.'0'.'0'.'0'.'50','0','0'.'FA;) 

arter  insert  into  Contacts?  vaiues('APF04','67.50'.'33.50','1  ?9.00'.'1 07.5','97’,'0'.'0'.'0'.'0'.'0‘,'0','0','0','0','50'.'0'.'0','FA;) 

insert  into  Contacts?  valuesC‘APF09'.'7?.50','30.00'.'1 30.00', ‘28. 4'.'1 20'.'0','0','0','0',‘0','0'.'0'.'0'.'0'.'70','30.??'.'1 30.1 4','N;) 

arter  insert  into  Contacts?  vaiues('APF09','72.50'.'30.00‘,'1 30.00'. •28.4','1 20', 'O'. 'O'. ‘O'. 'O'. 'O', 'O', 'O', 'O',  13'. '70'. ‘30. 22', '1 30.1 4'.‘N;) 

insert  into  Contacts?  values('APF09'.‘73.00',‘30.00'.‘1 30.00‘,'24.2’.‘1 20',’0', 'O', 'O', “O', ‘O’. 'O’. ‘O'. ‘O'. 'O', '70', '30.23'. '1 30.1 3','N;) 

arter  insert  into  Contacts?  vaiues('APF09','73.00'.‘30.00','1 30. 00'. '24. 2', '1  20', 'O’. 'O'. 'O'. 'O'. 'O', 'O', 'O', 'O', 'O’. TO’. '30. 23', '1 30.1 3','N;) 

insert  into  Contacts?  values(’APF08'.75.00','29.00'.'1 29.00',’326.6'.'983','0','0','0','0','0'.'0'.'0'.'0'.'0‘,'1 00', 'O', D', 'FA;) 

arter  insert  into  Contacts?  vaiues('APF08','75.00'.‘?9.00','1 29.00'.'326.6','983'.'0'.'0'.'0'.'0'.'0’,'0','0','0'.’0'.'1  OO'.'O'.'O'.'FA;) 

insert  into  Contacts?  values('APF03'.‘75.50','33.50'.'1 28.50', '1 1  2.9'.'381  ’.'0’,'0',13',13‘,'0'.'0'.'0'.‘0'.'0','50','0',13','FA;) 

arter  insert  into  Contacts?  vaiues('APF03','75.50'.'33.50‘,'1 28.60'.‘1 1 2.9‘,'381  '.'0'.‘0'.'0'.'0','0','0','0',13',‘0'.'50'.'0'.'0'.'FA;) 

insert  into  Contacts?  values('APF08'.‘76.50','29.00'.'1 29.00', '1 24. 2'. '96'. 'O'. 'O', 'O', 'O',  13’. 'O'. 'O'. 'O'. 'O'.'l  OO'.'O'.'O’.’FA;) 

arter  insert  into  Contacts?  vaiues('APF08‘,'76.50'.'29.00','1 29.00'.'1 24.2', '96', 'O'. 'O'. 'O'. 'O'. 'O', 'O', 'O', 'O’, 'O',  1 0O'.'O'.'O'.'FA;) 

insert  into  Contacts?  vaiuesrAPF08'.‘77.50','29.00'.'1 29.00',‘228.8'.'1 00'.'0','0','0','0','0'.'0'.'0'.'0','0'.'1 00','28.74'.'1 28.66','U;) 

arter  insert  into  Contacts?  vaiues('APF08','77.50'.'29.00','1 29. 00'. '228.8', '1 00','0'.'0'.'0'.'0','0’,'0','0','0',13'.'1 00'.’28.74','1 28.66'.'U;) 

insert  into  Contacts?  valuesC‘APF08'.'78.00','?9.00'.'1 29.00', ‘21  3. O'.'l  00'. '1 50',‘0',13',‘0'.’0'.'0'.'0'.'0’,'0’,'1 00',’?8.73'.'1 28.80', “U;) 

arter  insert  into  Contacts?  vaiues('APF08','7e.00'.‘29.00‘,'1 29.00'. ’21 3.0‘,'1 00'. '1 50'. ‘O'. 'O'. 'O', 'O', 'O', 'O'.  13'. ‘O'.'l  00'. '28.73', '1 28.80'.'U;) 

insert  into  Contacts?  values('APF07'.‘78.50','28.00'.‘1 28.00', ‘48. 6'. ‘1  OO'.’O', 'O', 'O', “O', ‘O’, 'O’. 'O'. ‘O'. 'O'.'l  00', '28. 72’. ‘1 28.94','U;) 

arter  insert  into  Contacts?  vaiues('APF07‘,'78.50'.‘28.00','1 28. 00'. '48.6', '1 00', 'O’. 'O', 'O'. 'O'. 'O', 'O', 'O', 'O', 'O’.'l  00’, '28. 72', '1 28.94'.'U;) 

insert  into  Contacts?  values(’APF08'.‘78.50','29.00'.'1 29.00',1 90.4'.'1 00', '1 50','0',13','0'.'0'.'0'.'0'.'0‘,'0','1 00','28.72'.'1 28.94','U;) 

arter  insert  into  Contacts?  vaiues('APF08',’78.50'.‘?9.00','1 29.00'.'1 90.4‘,'1  OO'.’t  50'.'0'.'0'.'0','0','0','0'.’0'.'0'.'1 00'.'?8.7?','1  ?8.94'.'U;) 

insert  into  Contacts?  values('APF08'.'79.00','?9.00'.'1 29.00', '1 6e.3'.'1 00’. '1 50',13',13‘,'0'.'0'.'0'.‘0'.'0','0’,'40',’?8.71  '.'1 29.07', “U;) 

arter  insert  into  Contacts?  vaiues('APF08','79.00'.'29.00‘,'1 29.00'.'1 68.3‘,1  OO'.'t  50'.'0'.'0','0','0','0',13',’0'.'0'.'40'.'28.71  ',1 29.07'.‘U;) 

insert  into  Contacts?  values('APF08'.‘79.50','29.00'.’1 29.00', '1 51  .S'.'l  00'. '1 50', 'O', “O', 'O’. 'O'. 'O'. 'O'. 'O', 'O', '40', '28. 68'. '1 29.1 8','U;) 

arter  insert  into  Contacts?  vaiues('APF08‘,'79.50'.'29.00','1 29.00'.'1 51 .8',1 00’, '1 50'. 'O'. 'O'. 'O', 'O', 'O', 'O', 'O'. 'O'. '40'. '28. 68', '1 29.1 8'.'U;) 

insert  into  Contacts?  valuesCAPF08'. '80.00', '29. OO'.'1 29.00','1  42.8'.'1 00'. '1 60','0','0','0'.'0'.'0'.'0','0','0','40','28.65'.'1 29.29',U;) 

arter  insert  into  Contacts?  vaiues('APF08','80.00'.'29.00','1  ?9.00'.'1 42.8', '1 00', ‘1 50'.'0'.'0','0','0','0','0',13','0'.'40'.'28.65','1  ?9.29'.'U;) 

insert  into  Contacts?  valuesC‘APF08'.'80.50','?9.00'.'1  ?9.00','1 35.7'.'0'.'1 50’,'0',‘0',13','0'.’0'.'0'.'0'.'0’,'40’,'?8.63'.'1  ?9.38','U;) 

arter  insert  into  Contacts?  vaiues('APF08',’80.50'.'29.00‘,'1 29.00'. ’1 35. 7', 'O'.'l  50'. 'O'. 'O'. 'O', 'O', 'O', 'O', 'O',  13'. '40'. ‘28. 63', '1 29.38'. 'U;) 

insert  into  Contacts?  values('APF08'.’81 . 00', '29. 00'. ‘1 29.00', ‘49. 6'. ■734',’0', 'O', 'O', “O', ‘O’. 'O’. ‘O'. ‘O'. 'O'.'l  OO'.'O'.'O'.’FA;) 

arter  insert  into  Contacts?  vaiues('APF08',’81 .00'. '29.00', '1 29.00'.'49.6','734’,'0’.'0'.'0'.’0'.'0','0','0','0','0’.'1  OO'.'O'.'O'.'FA,') 


Figure  9.  Data-to-Database  Agent  results  display. 
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Figure  10.  Cross-Fix  Display  Agent  input  control  screen. 


Figure  1 1 .  Cross-Fix  Display  Agent  results  display. 
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Figure  12.  Temporal-Proximity  Display  Agent  results  display. 
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Figure  13.  Alarm  (User-Notification)  Agent  results  display. 
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Figure  14.  URL-Reader  Agent  input  control  screen. 
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Figure  15.  Result  of  Cross-Fix  Display  Agent. 
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Figure  16.  Result  of  Temporal-Proximity  Agent. 


Figure  17.  Contact-Query  Panel  that  generates  a  search  string  for  Contact-Report  Crawler. 
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The  results  of  applying  the  agents  to  another  simulated  data  set  are  shown  in  Figures  15  and  16. 
This  example  is  like  the  one  shown  in  Figures  1 1  and  12,  except  that  Figures  15  and  16  illustrate  the 
option  to  display  only  the  cross-fixes  as  small  circles  and  not  the  lines  of  bearing.  This  option  helps 
reduce  screen  clutter.  Two  concentric  circles  are  drawn  around  sensors  that  have  variable  detection 
ranges  due  to  obstacles,  such  as  islands,  in  their  vicinity. 

Figure  17  shows  the  Contact-Query  input  screen  from  which  an  operator  would  deploy  an  agent  to 
search  the  secure  network  for  LOBs  that  cross  a  specified  line  of  bearing  for  which  the  operator 
wanted  additional  information.  When  finished  executing,  the  Contact-Report  Crawler  would  list  the 
URLs  that  have  the  desired  information. 

3.3  DETERMINING  THE  VALIDITY  OF  CROSS-FIXES  AND  THEIR  COMPONENTS 

When  the  Cross-Fix  Display  Agent  associates  validated  LOBs  with  a  crossing  LOB  from  the 
contacts  database,  the  false  LOB  detections  that  do  not  cross  any  other  LOB  will  be  eliminated.  The 
Cross-Fix  Display  Agent  finds  all  of  the  LOBs  that  cross  each  other,  regardless  of  timing  and 
regardless  of  LOB  validity  with  respect  to  false  alarms.  Because  the  LOBs  are  line  segments  to  a  first 
approximation,  the  maximum  detection  range  will  determine  the  length  of  these  LOBs,  not  to  extend 
beyond  the  maximum  range,  which  ensures  the  geofeasibility  of  observed  LOBs  involved  in  cross¬ 
fixes. 

As  described  above,  the  Temporal-Feasibility  Agent  searches  the  cross-fix  data  to  determine 
which  ones  were  observed  within  the  specified  time  interval  of  each  other.  This  window  is  typically  a 
half  an  hour.  When  the  Temporal-Proximity  Agent  screens  out  cross-fixes  with  time  signatures  that 
do  not  fall  within  this  specified  time  interval  of  each  other,  the  LOBs  that  were  observed  outside  of 
these  time  intervals  are  excluded  from  further  consideration. 

False  LOBs  are  generated  according  to  a  stochastic  process  in  the  M&S  program,  whereas  valid 
LOBs  that  represent  correct  detections  of  platforms  with  valid  crossing  LOBs  represent  a  systematic 
process.  Thus,  the  Temporal-Proximity  Agent  can  eliminate  many  (but  not  all)  false  LOBs  because 
few  of  them  will  cross  other  LOBs  that  occur  within  in  the  specified  time  period  of  each  other. 

The  Cross-Fix  Display  Agent  and  the  Temporal-Feasibility  Agent  indirectly  screen  out  most  false 
LOBs  as  described  above.  Direct  screening  of  the  remaining  data  sets  to  eliminate  all  other  false 
alarms  with  total  certainty  becomes  much  more  difficult  at  this  point  because,  theoretically,  a  false 
alarm  can  be  generated  with  any  spectral  characteristics,  including  those  of  known,  valid  platforms. 
Such  a  false  alarm  will  be  indistinguishable  from  an  actual  correct  detection  except  by  association 
with  other  cross-fixes  that  occur  within  the  same  track. 

If  all  the  LOBs  observed  in  a  track  that  consists  of  cross-fixes  screened  in  the  manner  described 
above  have  the  same  spectral  signature,  these  cross-fixes  correctly  are  components  of  the  track  that 
belongs  to  the  same  valid  platform.  However,  if  the  spectral  signature  of  an  LOB  in  a  cross-fix  that 
appears  to  be  a  member  of  this  track  is  very  different  from  that  of  the  other  LOBs  comprising  the 
track,  one  can  surmise  that  the  LOB  with  the  different  signature  is  not  a  valid  member  of  the  track. 

It  could  belong  to  a  different  track  or  it  could  be  a  false  alarm. 

The  design  calls  for  the  agents  to  attempt  to  classify  each  contact  by  comparing  spectral  (source 
frequency)  signature  data  in  the  LOB  records  against  that  of  known  platforms,  including  targets  of 
interest  maintained  in  appropriate  databases.  This  classification  helps  determine  whether  the  cross- 
fixes  belong  to  known  platforms.  However,  it  will  not  be  sufficient  to  identify  the  cross-fixes  that 
have  false  alarms,  or  a  track  generated  by  an  unknown  platform  whose  data  are  not  stored  in  the 
characteristics  database. 
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4.  GEOGRAPHIC  ALGORITHMS 


The  three  equivalent  methods  were  implemented  for  finding  cross-fixes  areas  as  follows. 

1.  The  Parametric  Method  is  described  in  Section  4.1.  This  method  consists  of  solving  two 
simultaneous  linear  parametric  equations  to  find  the  latitude  and  longitude  of  the  intersection  point. 

2.  The  Vector  Theorem  Test  is  described  in  Section  4.2.  The  result  of  this  algorithm  represents 
the  truth  or  falsehood  of  a  cross-fix  but  does  not  determine  the  point  of  intersection. 

3.  A  Vector  Cross  Product  Test  also  was  developed  to  find  the  latitude  and  longitude  of  the 
intersection  point. 

4.1  THE  PARAMETRIC  METHOD— LOB  INTERSECTION  ALGORITHM 

The  geometry  for  the  LOB  intersection  algorithm  is  illustrated  in  Figure  18.  Let  Si  and  S2  be  two 
sensor  systems  with  maximum  detection  ranges  (MDRs)  of  ri  and  r2,  respectively.  Note  that  since 
acoustic  or  electromagnetic  energy  propagates  along  geodetic  (great  circle)  paths,  the  ranges  ri  and  ri 
are  not  simply  radii  of  circles.  Similarly,  LOBs  from  sensor  to  target  are  not  rhumb  (constant  bear¬ 
ing)  lines.  The  reported  LOB  of  a  contact  by  a  sensor  is  defined  as  the  initial  bearing  of  the  geodetic 
line  at  the  sensor,  as  the  bearing  generally  changes  along  the  path  of  the  geodetic. 

Let  0\  and  6^  be  the  reported  LOBs  for  concurrent  contacts  detected  by  sensors  Si  and  S2, 
respectively.  If  geodetic  line  segments  corresponding  to  these  LOBs  intersect  within  their  respective 
MDRs,  the  location  of  a  potential  target  responsible  for  the  LOBs  may  be  determined  as  follows: 

1.  Given  the  latitude  ^ziand  longitude  A,  of  sensor  Si  (the  departure),  compute  the  latitude  ^zi'and 
longitude  A' of  the  location  Di  (the  destination)  at  MDR,  ri,  along  the  geodetic  line  from  Si  with 
initial  LOB, 

/I '  =  /I  +  tan  '  [sin  sin(rj  /i?)/(cos  cos(rj  /i?)  -  sin  sin(rj  /i?)  cos  )] 

(j)'  =  tan  '[(sin^zicos(rj/i?)  -t-cos^zisin(rj/i?)cos^i)sin(/l'  -/l)/sin^j  sin(rj/i?)] 


Si(;i, 


Figure  18.  Geometry  of  two  intersecting  sensor  systems. 
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Here,  all  angles  are  expressed  in  radians,  and  rilR  is  the  angle  at  the  center  of  the  earth  subtending 
the  geodetic  segment  ri.  is  defined  as  the  radius  of  the  earth.  Similarly,  compute  the  destination  D2 
along  the  geodetic  line  from  sensor  S2. 

2.  Transform  the  geographic  coordinates  (A,  (j))  of  the  endpoints  of  each  geodetic  line  segment 
into  rectangular  coordinates  (x,  y)  using  the  Gnomonic  projection: 

X  =  cos^zisin(/l-/lQ)/ cosc 
y  =  [cos  (pQ  sin  (p  -  sin  (p^  cos  (p  cos(/l  -  /Iq  )]  /  cos  c , 

where  cos c  =  sin (p^  sin (p  +  cos (pQ  cos (p  cos(A  -Aq).  Here,  the  central  parallel  ^  and  the  central 

meridian  Ao  define  the  center  of  the  projection  (i.e.,  the  point  of  tangency  of  the  projection  plane  on 
the  earth’s  surface),  which  may  be  situated  anywhere  in  the  same  hemisphere  as  the  line  segments  so 
that  cos  c  >  0.  The  Gnomonic  projection  transforms  any  geodetic  line  into  a  straight  line  on  the 
rectangular  (x,  y)  projection  plane.  Thus  the  transformed  rectangular  endpoints  (xi,  yi)  and  (x  j,  y  j) 
for  SiDi  and  (x2,y2)  and  (x  2,y  2)  for  S2D2  define  straight-line  segments  in  the  projection  plane. 

3.  Represent  the  straight  lines  containing  the  segments  SiDi  and  S2D2  by  the  parametric  representa¬ 
tions, 

(1  -/ijSi  +  ;?Di  and  (1  -  q)S2  +  qT>2, 

respectively,  where  Si  =  (xi,  yi),  Di  =  (x  j,  y  j),  and  S2  =  (x2,  y2),  D2  =  (x  2,  y  2).  The  intersection  (if 
any)  of  the  lines  occurs  where  these  parametric  representations  are  equal,  i.e.,  where  the  parameters  p 
and  q  are  determined  from  the  system  of  equations, 

(1  -  p)x^  +  px[  =  (1  -  q)x2  +  qx'2 
(1  -  P)yx  +  Py'i  =  (1  -  ^)T2  +  9T2  ’ 


or  upon  rewriting  in  matrix  form. 


(Xi'-Xi)  (X2-X2) 

p 

1 

1 

«N 

1 _ _ 

_(y'i-yi)  (t2-T2)_ 

_(T2  -Ti)_ 

If  this  system  of  equations  fails  to  yield  a  solution  (i.e.,  the  matrix  of  coefficients  is  singular),  the 
lines  are  parallel  or  coincide.  Otherwise,  if  0  <  />  <  1  and  0  <  q  <  1 ,  the  intersection  of  the  lines  will 
occur  within  the  line  segments  SiDi  and  S2D2. 

4.  Determine  the  rectangular  coordinates  (x,  y)  of  the  intersection  by  evaluating  the  parametric 
representations  for  either  p  or  q;  for  example, 

X  =  (1  -  p)Xi  +  px[ 

T  =  (1  -  p)yi  +  py'i  • 

5.  Transform  the  rectangular  coordinates  (x,  y)  of  the  intersection  into  geographic  coordinates  (A,  </>) 
using  the  inverse  Gnomonic  projection: 

=  sin  '  [cos  c  sin  +  (y  sin  c  cos  /  /?)] 

A  =  Ag  +  tan  '[x sine /(/? sin cosc  -ysin^zig  sine)], 
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where  p  =  (x^  +  and  c  =  tan  '  (p) .  If  p  =  0  then  ^  ^  and  A=  Ao.  Also,  if  ^  =  +90°,  then 

A  =  Aq  +  tan^'[x/(+_y)] . 

4.1.1  Algorithm  for  Computing  the  Intersection  of  Two  Bearings  on  the  Earth 

The  following  algorithm  computes  the  longitude  A  and  latitude  (j)  of  the  intersection  of  two 
bearings  and  from  two  known  locations  Pi(/li,  (pi)  and  P2(/i-2,  (h),  respectively.  By  convention, 
latitudes  are  specified  between  +;r/2  with  north  latitudes  positive  and  south  latitudes  negative; 
longitudes  are  specified  between  +;rwith  east  longitudes  positive  and  west  longitudes  negative. 
Bearings  are  specified  between  +;rwith  bearings  increasing  in  the  clockwise  direction  and  with  0 
coinciding  with  true  north.  The  geometry  of  the  general  case  is  shown  in  Figure  19,  where  all  curves 
are  arcs  of  great  circles  on  the  surface  of  a  sphere.  LOBs  from  points  Pi  and  P2  are  shown  as  solid 
curves.  Meridians  at  longitudes  A\,  A2,  and  A  are  shown  as  dashed  curves  from  the  north  pole  N 
through  points  Pi,  P2,  and  P,  respectively.  Note  that  spherical  triangle  sides  are  specified  as  the  angle 
at  the  center  of  the  sphere  subtending  the  side. 


Figure  19.  Spherical  geometry  of  bearing  intersection  computation. 


For  triangle  ANPi^P?: 

1.  Compute  sine  and  cosine  of  angle  subtending  side  512:  From  the  Law  of  Cosines  for  sides  of 
spherical  triangles. 


and 


cosi’jj  =  cos(y-^i)cos(y-^2)  +  sin(f-^)sin(-|-^2)cos(/l2  -A^) 

=  sin  sin  ^2  +  cos  cos  ^2  cos(/l2  -  ^ ) 
sinvi2  =  (1 -cos^  . 


2.  Compute  angles  ai  and  a2:  From  the  Law  of  Sines  for  spherical  triangles, 

sinttj  _  sin(/l2  - /Ij ) 
sin(f  -(P2)  sin  ^12 
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that  is, 


sin  ctj  =  sin(f  -  )  sinC/lj  -  /Ij  )/sin  5 

=  cos(/)2  sin(/l2  -/li)/sin 


5j2  . 

From  the  Law  of  Cosines  for  sides  of  spherical  triangles, 

cos(f  - <2^2 )  =  cos(f  -(/)y) cos 5i2  +  sin(y -(/)^) sin 5i2  cos 
sin  ^2^2  =  sin  cos  5j2  +  cos  (j)^  sin  ^12  cos  , 
and  after  some  manipulation, 

cos  =  [cos  ^z^i  sin  ^2^2  -  sin  (j)^  cos  ^2^2  cos(/l2  -  /ii )]/ sin  ^12  . 


Thus, 


tana,  = 


sma 


cos^2siii(^  ~A) 


'  cos  aj  cos  ^  sin  ^2  “  sill  ^  cos  ^2  cos(/l2  -  ^ ) 

cos^2siii(^ 


aj  =  tan 


Similarly, 


a2  =  tan^ 


cos ^  sin ^2  “ sin ^1  cos ^2  cos(/l2 
cos  (j)^  sin(/l2  -  /Ij ) 


sin  (j)^  cos (j)^  -  cos  (f)^  sin  (j)^  cos(/l2  -  \) 

For  triangle  AP^^P??: 

3.  Compute  angles  71  and  72: 

=  «i  -  A 
7  2  ~  <^2  P2  • 

4.  Compute  sine  and  cosine  of  angle  73:  From  the  Law  of  Cosines  for  angles  of  spherical  triangles, 

cos  73  =  -  cos  7i  cos  72  +  sin  7j  sin  72  cos  5’i2 
and 

sin  73  =  (1  -  cos^  73  . 

5.  Compute  sine  and  cosine  of  angle  subtending  side  s^:  From  the  Law  of  Sines  for  spherical 
triangles, 

sin5i3  sin5j2 


sm  72  sm  73 

that  is, 

sin  5(3  =  sin  72  sin  ^12 /sin  73  . 

From  the  Law  of  Cosines  for  angles  of  spherical  triangles, 

cos  72  =  -  cos  7i  cos  73  +  sin  7j  sin  73  cos  513 , 

that  is. 
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cosi’jj  =  (cos  72  +C0S7jC0S73)/(sin7jSin73). 


For  triangle  ANPi^P: 

6.  Compute  latitude  (f>\  From  the  Law  of  Cosines  for  sides  of  spherical  triangles, 


and 


cos{^-(f>)  =  cos(y-^j)cos5’j3  +sin(Y-^j)sin5'j3  cosy^j 

sin^  =  sin^j  cos5’j3  +  cos^  sin5'j3  cos  |3^ 
cos^zJ  =  (1  -sin^  . 


Thus, 


tan^  =  sin^/cos(zi 

(p  =  tan  '[sin^/cos^]. 


7.  Compute  longitude  A\  From  the  Law  of  Sines  for  spherical  triangles. 


that  is. 


sin(/l  -  /I, )  _  sin  /3^ 
sin5j3  sin(f-^zi)’ 


sin(/l-/l,)  =  sin5'j3siny0j/sin(y-^) 
=  sin5'j3siny0j/cos^. 

From  the  Law  of  Cosines  for  sides  of  spherical  triangles. 


cos  5j3  =  cos(y  -(pP)  cos(y  -  (p)  +  sin(y  -  )  sin(  Y  -  (p)  cos(/l  -  /Ij ) 
=  sin  sin  ^  +  cos  cos  ^  cos(/l  -  /Ij ) 
cos(/l  -  /I,)  =  (cos5’j3  -sin^j  sin^)/(cos^j  cos^). 


Thus, 


tan(/l  -/Ij) 


sin(/l  -/Ij) 
cos(/l  -/Ij) 


A=Ay+  tan 


sin(/l-^) 
cos(/l  -^) 


4.2  THE  VECTOR  THEOREM  TEST  METHOD— LOB  INTERSECTION  ALGORITHM 

Two  conditions  are  necessary  and  sufficient  to  demonstrate  intersection  between  line  segments. 

Condition  1:  Two  line  segments  do  not  intersect  if  and  only  if  one  segment  lies  entirely  to  one 
side  of  the  line  containing  the  other  segment.  Referring  to  Figure  20,  (ps  -  P2)  x  (pi  -  P2)  and  (p4  -  P2)  x 
(pi  -  P2)  are  both  positive. 
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Figure  20.  Line-segment  geometry  for  cross-fix  test — no  intersection. 

Condition  2:  Two-line  segments  interseet  if  and  only  if  each  of  the  two  pairs  of  cross  products 
in  Figure  21  have  different  signs  (or  one  cross  product  in  the  pair  is  0). 

(pi  -  P4)  X  (p3  -  P4)  and  (p2  -  P4)  X  (p3  -  P4)  =>  The  line  through  (p3  -  P4)  intersects  the  line 
through  (P1-P2). 

(P3  -  P2)  X  (pi  -  P2)  and  (p4  -  P2)  X  (pi  -  P2)  =>  The  line  through  (pi  -  P2)  intersects  the  line 
through  (P3-P4)- 


Figure  21 .  Line-segment  geometry  for  cross-fix  test — intersection. 


4.3  THE  GEO-FEASIBILITY  FILTRATION  PROCESS 

The  geo-feasibility  filtration  process  filters  out  proposed  cross-fixes  that  arise  from  sensors 
whose  detection-coverage  area  do  not  overlap  with  each  other.  The  remaining  cross-fixes  are 
considered  geographically  feasible.  Figure  22  depicts  two  sensors  with  overlapping  detection 
coverage,  and  two  without  overlap.  The  sensors  are  depicted  as  dots  inside  of  small  circles  and  the 
maximum  detection  ranges  are  depicted  as  the  large  circles.  First,  sensor  overlap  is  a  necessary  but 
insufficient  condition  for  valid  cross-fixes.  For  example,  the  distance  between  sensor  1  and  sensor  2, 
d,  should  be  less  than  the  sum  of  the  maximum  detection  ranges,  d  <  R1  -I-  R2,  as  shown  in  Figure  22. 
This  guarantees  sensor  overlap.  The  best  and  most  definitive  detections  occur  when  the  LOBs  cross 
at  90  degrees. 


Figure  22.  Role  of  sensor  geometry  in  the  geo-feasibility  screening  process. 


In  contrast,  the  worst  cases  occur  when  the  LOBs  are  collinear,  which  can  happen  when  each  LOB 
in  the  cross-fix  points  to  the  other  sensor,  and  the  platfonu  detected  is  between  the  two  sensors,  on 
the  line  segment  that  connects  them  (Figure  23a).  ft  also  can  happen  when  the  LOBs  point  in  the 
same  direction  when  the  platform  is  located  on  a  line  extrapolated  in  either  direction  from  this  line 
segment.  Even  when  the  distance  between  the  sensors  is  less  than  the  sum  of  the  maximum  detection 
ranges,  a  cross-fix  will  not  occur  if  the  LOBs  are  oriented  away  from  each  other,  as  is  the  case  in 
Figure  23b.  Moreover,  a  LOB  originating  from  a  sensor  is  not  compared  against  any  other  LOB 
originating  from  that  same  sensor.  True  cross-fixes  cannot  occur  in  these  cases,  which  are  called 
“degenerate  cross-fixes”  because  the  information  obtained  from  them  is  not  specific  enough  to  help 
locate  the  platform. 
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Figure  23.  Examples  of  “degenerate  cross-fixes.” 
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5.  SENSOR  ONTOLOGY  STRUCTURE  AND  INTEGRATION 


Sensors  can  be  classified  in  various  ways,  such  as  by  the  physical  property  they  detect,  by 
whether  they  are  active  or  passive,  by  their  accuracy,  by  their  availability,  by  their  owner,  etc. 

In  an  integrated  sensor  ontology,  these  various  ways  of  classifying  sensors  are  represented 
by  multiple  inheritance  links  (Ceruti  &  Wilcox,  2006).  The  sensor  ontology  also  is  documented 
in  Swanson  et  al.  (2007). 

A  survey  of  existing  sensor  ontologies  reported  in  Ceruti  et  al.  (2005)  summarized  some  of  the 
mappings  for  the  ontologies  found  in  the  survey.  Several  ontologies  were  found  but  all  were 
incomplete  and  no  two  ontologies  were  exactly  alike.  No  single  ontology  included  all  of  the 
concepts  in  sensor-data  acquisition,  fusion,  interpretation,  and  usage,  nor  did  any  of  the  existing 
ontologies  include  all  of  the  concepts  of  any  other  sensor  ontology.  Moreover,  the  ontologies 
found  in  the  survey  addressed  primarily  noun  concepts  and  did  not  contain  explicit  references 
to  verbs,  with  the  possible  exception  of  Cyc  (Cycorp,  2002;  Reed  &  Lenat,  2002),  which  covers 
some  sensor-related  verb  concepts  implicitly  in  its  upper  ontology.  Some  concepts  that  occur 
in  one  ontology  also  can  occur  in  another  ontology  but  at  a  different  level,  as  shown  for  the 
hypothetical  example  in  Figure  24  (Ceruti  &  Wilcox,  2006),  where  a  concept  at  level  2  in  ontol¬ 
ogy  A  also  occurs  in  ontology  B,  but  at  level  3. 


ONTOLOGY  A  ONTOLOGY  B 


LEVEL: 

3 

2 

1 


^  =  CONCEPTS  IN  ONTOLOGY  A 
O  =  CONCEPTS  IN  ONTOLOGY  B 

Figure  24.  Example  of  a  concept  that  occurs  at  different  levels  of  abstraction  in  different  ontologies 
(Ceruti  &  Wilcox,  2006). 

Some  noun  concepts  that  pertain  to  sensor  fusion  were  not  found  explicitly  in  any  of  the 
surveyed  ontologies.  For  example,  although  ‘signal’  was  found  in  three  of  the  ontologies  (Ceruti 
et  al.,  2005;  Gao,  2000;  and  Reed  &  Lenat,  2002),  characteristics  that  pertain  to  signals  such  as 
“frequency,”  “period,”  “wavelength,”  “pulse-repetition  rate,”  “signal  strength,”  and  “spectrum,” 
were  not  covered  explicitly.  Also,  the  concept  of  “noise”  was  not  covered  in  the  sensor 
ontologies,  although  it  could  be  part  of  a  more  general,  upper  ontology.  Concepts  associated  with 
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noise,  such  as  “broadband”  and  “narrowband”  were  not  found.  The  concept  of  a  “propagation 
medium,”  such  as  “air,”  “water,”  and  “space”  did  not  occur  explicitly  in  any  surveyed  ontology, 
although,  here  again,  it  may  be  present  in  an  upper  ontology  that  does  not  pertain  specifically  to 
sensors.  Depending  on  the  placement  of  these  concepts  within  the  ontological  structure,  the 
specific  data-fusion  concepts  will  inherit  characteristics  from  the  higher  and  more  general  levels 
of  abstraction  (Cemti  &  Wilcox,  2006). 

In  Figure  26  (Ceruti  &  Wilcox,  2006;  Russomanno  et  al.,  2005a  and  b),  the  various  ontologies  are 
as  follows:  “VIS  Sensor  Ontology”  (Ceruti  et  al,  2005),  Cycorp’s  Cyc  ontology  for  sensor  concepts 
(Reed  and  Lenat,  2002),  the  Formal  Information  Fusion  Framework  (Gao,  2000),  J.  Hendler’s  sensor 
ontology  in  DARPA  Agent  Markup  Language  (DAML)  (Hendler,  2004;  McGuinness  et  al.;  2002; 
and  Bechhofer  et  al.,  2004),  and  OntoSensor  (Russomanno  et  al.,  2005a  and  b).  Because  defense- 
related  standards  are  based  on  concepts  that  pertain  to  sensors  and  their  utilization,  a  complete 
integrated  ontology  will  include  concepts  from  these  standards.  For  example,  the  ontology  implicit  in 
the  standard  Naval  Tactical  Display  System  Symbology  (NTDS)^  (Lead  Standardization  Activity, 
1999;  NATO  MAS,  1990)  has  concepts  that  pertain  to  sensors  and  level-one  sensor  fusion.  Other 
examples  shown  in  Figure  25  include  XML  registry  and  the  DoD  Discovery  Metadata  Standard 
(DDMS)  (DoD,  2007). 


Figure  25.  Sensor  ontology  and  platform  symbology  integration  (Ceruti  &  Wilcox,  2006;  DoD,  2007; 
Russomanno  et  al.,  2005a  and  b). 
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The  concept  of  ontology-based  data  fusion  is  discussed  in  Llinas  et  al.  (2004).  Content  ontology 
specifies  concepts  that  include  a  description  of  what  is  believed  to  be  the  true  nature  of  objects 
(Llinas  et  al.,  2004).  The  content  ontology,  together  with  the  states  of  interest  associated  with  a  task 
and  the  relationships  within  and  between  these  states,  are  also  are  important  parts  of  a  sensor 
ontology.  This  ontology  also  includes  concepts  about  the  distinction  between  observations  such  as 
signals  from  sensors  and  the  objects  that  give  rise  to  these  signals.  Using  a  complete  sensor  ontology 
and  database  of  sensor-performance  characteristics,  intelligent  agents  can  obtain  data  available  on  the 
secure  network  more  efficiently  (Ceruti  &  Wilcox,  2006).  The  ontology  also  is  the  basis  for  the 
sensor-model  design  and  the  C&P  database. 

5.1  AGENT-ONTOLOGY  INTERACTIONS 

Top-level  Java®  classes  for  constructing  KMDT  agents  were  developed  knowing  that  the  agents’ 
tasking  would  involve  sensor  data  processing  including,  but  not  limited  to,  data  retrieval,  storage, 
and  fusion.  Thus,  the  concept  of  operations  calls  for  the  agents  to  interact  with  an  integrated  sensor 
ontology  (Ceruti,  2004;  Ceruti  &  Wilcox,  2006;  Matheus  et  al.,  2005)  to  coordinate  their  tasks 
directly  or  indirectly  through  databases  designed  according  to  the  ontology  (see  the  Section  5). 

The  ontology  and  associated  databases  document  the  sensor  and  platform  characteristics  and 
capabilities.  They  inform  the  agents  of  the  appropriate  sources  of  data  for  a  particular  task  so  the 
agent  will  search  only  for  information  relevant  to  the  task.  Agents  might  consult  the  ontology 
to  identify  classes  of  sensors  that  can  detect  a  certain  type  of  contact,  thus  limiting  the  subsequent 
search  space  to  include  only  those  sensor  types.  For  example,  it  would  be  unproductive  to  search 
Web  sites  of  space-based  sensors  for  specific  information  to  help  identify  or  classify  a  contact  when 
the  signal  in  question  is  known  to  originate  from  a  submarine. 

The  sensor  ontology  and  associated  databases  also  supply  knowledge  to  the  agents  to  aid 
subsequent  data  fusion.  If  two  sensors  of  the  same  type  (homogeneous  sensors)  detect  the  same 
signal,  their  signal  signatures  can  often  be  compared  directly.  However,  data  fusion  for  dissimilar 
(heterogeneous)  sensors  is  often  more  difficult  because  a  direct  comparison  of  the  signal  signatures 
is  usually  impossible.  In  this  case,  an  ontology  is  especially  useful.  If  an  unknown  contact  is  detected 
by  disparate  sensors,  agents  can  use  the  ontology  to  identify  classes  of  TOl  that  can  be  detected  by 
each  sensor  type,  whose  intersection  is  likely  to  contain  the  unknown  contact,  thus  aiding  in  subse¬ 
quent  classification. 

As  a  simple  example,  suppose  an  underwater  acoustic  sensor  detected  some  unknown  contact  at  the 
same  time  a  space-based  electromagnetic  sensor  also  detected  an  unknown  contact.  Knowledge 
extracted  from  the  ontology  might  indicate  that  the  likely  acoustic  contact  was  either  an  undersea 
or  surface  vessel,  whereas  the  ontology  might  suggest  that  electromagnetic  contact  was  a  surface  ship 
or  an  aircraft.  Taken  together,  the  intersection  of  these  two  sets  of  platforms  would  imply  that  the 
contact  was  a  surface  target  if  the  respective  detections  were  correlated. 
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6.  RESULTS  AND  DISCUSSION 


To  illustrate  the  operation  of  the  KMDT  agents  in  localizing  contacts  from  intersections  of  LOB 
data  obtained  from  separate  platform  sensors,  many  simulations  were  conducted  on  a  scenario  in  the 
East  China  Sea  involving  8  target  vessels  and  1 1  passive  acoustic  sensors  (Figure  2).  During  the 
execution  of  one  simulation  representing  72-hours,  400  contact  reports  (including  false  alarms)  were 
generated  as  depicted  in  Figure  26.  The  results  demonstrate  the  success  of  the  KMDT  M&S  software, 
which  generates  both  correct  and  false-alarm  LOBs  in  the  simulation  process.  This  effect  also  is 
visible  in  Section  3  where  the  screen  shots  show  considerable  reduction  in  clutter  when  only  the 
temporally  feasible  cross-fixes  are  displayed.  The  relevant  figure  pairs  that  show  this  effect  are 
Figures  1 1  and  12  as  well  as  Figures  15  and  16. 

Figure  26  also  demonstrates  that  KMDT  can  reduce  the  information  overload  by  filtering  out 
irrelevant  information.  In  Figure  26a,  all  400  contact  FOBs  are  displayed.  However,  many  FOB 
intersections  do  not  represent  valid  target  locations  because  they  do  not  occur  simultaneously  (i.e., 
within  an  acceptable  time  window).  In  Figure  26b,  many  of  these  cross-fixes  are  filtered  out  by 
selecting  only  the  FOBs  observed  within  an  appropriate  temporal  correlation  interval,  in  this  case 
30  min.  The  30-min  time  window  corresponds  to  the  time  between  steps  in  the  simulation.  The  valid 
cross-fixes  would  be  those  that  occurred  in  the  same  simulation  step. 

While  the  agents  have  filtered  out  temporally  irrelevant  data,  the  simulated  data  set  may  still 
contain  false  LOBs.  The  following  test  was  conducted  to  determine  the  ability  of  agents  to  filter  out 
false  alarms  indirectly.  There  were  10  different  simulation  runs  that  yielded  a  total  of  5948  detection 
alerts,  906  of  which  were  false  alarms.  On  average,  3  percent  of  all  the  cross-fixes  generated  were 
temporally  feasible.  The  number  of  false  alarms  in  the  cross-fixes  that  were  temporally  feasible  was 
42.  The  false  alarms  statistics  were  determined  from  the  ground-truth  output  of  the  M&S  software. 
The  agents  were  not  programmed  to  ingest  or  calculate  any  data  on  false-alarms.  The  elimination  of 
the  false  alarms  is  an  appropriate  topic  for  future  research  (see  the  Section  7). 

The  agents  can  find,  access,  store,  process,  and  display  large  quantities  of  information  much  faster 
than  a  human  operator  can.  The  results  suggest  that  KMDT  can  improve  the  efficiency  of  detecting 
ships  and  submarines  to  reduce  information  overload  for  the  operator.  Agents  can  be  deployed  on  the 
network  to  obtain  additional  information  to  corroborate  or  refute  an  hypothesis  when  the  operator 
is  in  doubt  about  the  initial  results.  Experience  and  research  results  to  date  suggest  that  the  evolving 
KMDT  technology  can  provide  the  military  users  improved  future  capabilities,  such  as  reduced 
uncertainty  in  command  centers  and  fewer  target-selection  errors.  The  distributed-agent  architecture 
facilitates  scalability. 

Based  on  experience  with  the  KMDT  prototype,  the  KMDT  approach  appears  to  be  able  to 
increase  the  efficiency  of  contact-information  acquisition  and  fracking.  Moreover,  the  KMDT 
approach  can  facilitate  fracking  at  a  higher  level  of  fidelity.  Based  on  the  literature  review,  the 
current  technological  gaps,  and  experimental  observations  with  KMDT  agents,  distributed-contact 
tracking  can  be  more  productive  using  the  results  of  the  KMDT  project.  We  have  found  that  agents 
facilitate  access  to  multiple  information  sources  and  specialized  information. 
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Figure  26.  (a)  Screen  shot  showing  the  results  of  400  contact  reports  (LOBs)  and  agent  computa¬ 
tions  collected  during  a  simulated  72-hour  interval,  (b)  screen  shot  showing  only  LOBs  that  cross 
within  30  min  of  each  other  as  selected  by  the  agents. 
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7.  DIRECTIONS  FOR  FUTURE 
RESEARCH,  DEVELOPMENT,  AND  APPLICATIONS 

Based  on  the  results  of  the  current  KMDT  program,  more  work  is  needed  to  demonstrate  the  full 
capability  level  of  KMDT  and  to  advance  the  technology  to  a  level  where  it  can  contribute  to 
programs  of  record.  Specific  actions  are  as  follows: 

•  Improve  the  integrated  sensor  ontology,  incorporating  recent  (Goodwin  and  Russomanno, 
2006;  Niemann,  2007;  Preece  et  ah,  2007)  and  future  (Graybeal,  2007)  advances  in  sensor 
ontology  research  and  development,  sensor  network  prototype  environment,  sensor  domains, 
and  data  types. 

•  Integrate  more  concepts,  relationships,  and  standards  into  the  KMDT  integrated  sensor 
ontology  from,  for  example,  OntoSensor  (Russomanno  et  al.,  2005a  and  b),  and  the  Chemical 
Biological  Radiological  Nuclear,  and  Explosive  (CBRNE)  data  model  (Neimann,  2007). 

•  Configure  intelligent,  autonomous  agents  and  ontologies  to  identify,  acquire,  and  analyze 
track  information. 

•  Demonstrate  the  validity  of  cross-fixes  on  the  basis  of  acoustic  signatures,  explicit  Temporal- 
Feasibility  agent  computations,  and  information  from  additional  simulated  heterogeneous 
sensors.  Ensure  that  data  sets  returned  to  answer  the  operator’s  query  contain  only  the  cross¬ 
fixes  resulting  from  correct  and  valid  LOBs.  Thus,  the  probability  that  false  alarms  will  be 
flagged  as  valid  cross-fix  components  will  be  reduced  to  an  acceptably  small  value. 

•  Develop  a  flexible  and  operationally  relevant  human-computer  interface  supporting 
analytical  and  intuitive  styles  of  queries.  For  example,  the  operator’s  query  results  will  return 
in  a  graphical  format  like  the  screen  shot  depicted  in  Figure  27. 

•  Develop  testing  tools  that  verify  that  KMDT  can  transform  and  disseminate  relevant 
information  to  the  commander  in  sufficient  time  to  act. 

•  Demonstrate  reduced  uncertainty  in  command  decisions  in  operational  scenarios  based  on  a 
more  efficient  use  of  data  from  existing  sensors  that  are  better  correlated  and  utilized  in  a  net- 
centric  environment. 

•  Automatically  create  a  query  retrieval  cache  memory  that  includes  lists  of  the  contacts,  the 
queries  executed,  and  any  relevance  evaluations. 

•  Develop  software  to  enable  multiple  users  to  share  the  contact  query  results,  thus  permitting 
analysts  synergistically  to  build  on  the  work  of  others  to  create  queries.  This  development 
could  lead  to  more  results  than  a  single  user  could  obtain  or  achieve  working  alone. 

•  Eliminate  constraints  that  inhibit  analysts  working  together  even  if  they  are  distributed 
physically,  temporally,  and  technologically.  Team  members  can  work  offline  and  in  parallel 
to  improve  their  efficiency. 

In  the  current  design,  agents  acquire  simulated  message-level  data  from  remote  Web  portals  to  be 
fused  at  the  site  that  deployed  the  agents.  In  contrast,  a  future  design  could  require  the  agents  to 
process  the  message-level  data  from  the  Web  portals  remotely  at  the  site  from  which  the  data  are 
retrieved.  This  distributed  architecture  design  reduces  network  bandwidth  requirements.  This 
processing  method  is  designed  to  relieve  overloaded  operators  tracking  multiple  unknown  contacts 
and  who  may  have  deployed  several  agents  to  retrieve  data  on  each  one  (Ceruti  et  al.,  2005).  Future 
simulations  will  include  heterogeneous  sensor  models  and  active  systems  in  addition  to  passive 
acoustic  or  electromagnetic  sensors. 
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The  KMDT  architecture  fits  into  the  larger  overall  design  of  net-centric  Web  services  for  the 
warfighter.  KMDT  LOB  correlations  can  be  orchestrated  to  support  individual  users  and  their 
software  agents  in  the  net-centric  environment  where  the  next  service  utilization  depends  on  the 
outcome  of  current  services.  Good  orchestration  requires  good  semantic  understanding  of  services 
through  ontologies  (Daconta  et  ah,  2003). 
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Figure  27.  Screen  shot  depicting  a  query  result  as  a  future  enhancement  of  the  agent-user 
interface. 


The  authors  believe  that  analysts  will  be  more  satisfied  with  the  process  and  the  product  than 
analysts  whose  members  individually  track  a  contact  without  KMDT  and  then  combine  their  results 
after  they  finish  the  analysis. 

Our  future  research  objectives  are  to  refine  and  extend  the  design  and  implement  empirical 
experiments  to  test  our  theories  and  our  systems’  architecture,  interface,  and  functionality.  Then, 
based  on  the  results,  we  will  refine  the  prototype  to  eventually  develop  a  robust  KMDT  module  that 
can  be  effectively  integrated  into  network-centric  and  shipboard  environments.  If  this  proves  to  be 
successful,  we  also  have  plans  to  integrate  multidimensional  tracking  and  visualization  functionality. 
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APPENDIX  A 

HISTORY  OF  KMDT  SIMULATION  DEVELOPMENT 


Version  0 

•  Map  of  theater  of  operations 

o  Coastline  database 
o  Bathymetry  database 

•  Map  cursor  for  extracting  geographic  information 

•  Bathymetric  contours 

Version  1 

•  Multiple  targets 

o  Narrowband  source-level  spectmm  acoustic  signatures 

•  Quasi-random  target  motion  model 

o  Based  on  normal  distributions  of  speed  and  heading 
o  Land  avoidance  algorithm 

•  Multiple  (fixed)  sensors 

•  Passive  acoustic  sensor  model 

o  Transmission  Loss  model  (spherical  spreading  -I-  absorption) 
o  Ambient  Noise  model 

•  Probability  of  Detection  model  (range  dependent) 

•  Keyboard  interaction  with  drop-down  menu  options: 

o  Advance  time 
o  Show/hide  detection  log 
o  Show/hide  sensor  coverage 
o  Show/hide  map  cursor,  geographic  information 
o  Quit  simulation 

Version  2 

•  Scenarios  read  from  separate  script  files 

•  Detection  alerts/false  alarms  written  to  separate  text  files 

•  Menu  option  to  dynamically  change  simulation  time-step 

•  Additional  display  and  interface  modifications 

Version  3 

•  Graphical  improvements/enhancements 

o  Sensor  coverage  display 
o  Lines-of-bearing  alert  displays 
o  Restart  menu  option 

•  Detection  log  filenames  specified  through  scenario  file 

•  “Fuzzification”  of  reported  lines  of  bearing 

Version  4 

•  Added  interactive  control  via  mouse  and  cursor 
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Version  5 


•  Waypoint  motion  model  for  mobile  sensors 

•  Doppler-shifted  frequencies  due  to  target/sensor  motion 

•  Added  sensor  identification  labels  on  display 

Version  6 

•  Target  activation  delayed  until  specified  elapsed  time 

•  Propagation  time  delay  added  to  reported  elapsed  time 

•  Reported  frequency  resolution  increased  to  show  Doppler  effect 

•  Transmission  Loss  model  extended  to  include  cylindrical  spreading  loss 

•  GUI  improvements 

o  Individual  sensor  identification  and  maximum  detection  range  coverage  displayed  via 
cursor 

Planned  Improvements  for  Transition  Programs 

•  Modify  code  to  accommodate  aircraft 

o  Modify  quasi-random  motion  model  to  suppress  land  avoidance  restriction 
o  Modify  quasi-random  motion  to  specify  a  minimum  speed  for  fixed-wing  aircraft 
o  Add  altitude  profile  to  motion  models 

•  Add  additional  sensor  models 

o  Passive  electromagnetic 
o  Passive  electro-optic 

o  Add  line-of-sight  detection  range  computation 

•  Improve  acoustic  Transmission  Loss  model 

o  Sound  speed  environmental  database 
o  Surface  Duct  model 
o  Sound  Channel  model 
o  Convergence  Zone  model 

•  Improve  Source  Level  specification 

o  Narrowband  model 
o  Broadband  model 

•  Incorporate  bathymetry  contour  display  option 

•  Incorporate  screen  refresh  algorithm 

o  Video  memory  management 
o  Chained  code  segment  overlays 
o  Separate  video  pages  (EGA) 

•  Build  capability  to  specify  different  theaters  of  operation 

o  Specification  via  scenario  file  or  separate  interactive  module 

o  Algorithm(s)  to  automate  selection  of  maneuver  polygon  (use  coarse  resolution  coastline 
database?) 

•  Build  non-graphical  version  of  the  simulation  to  facilitate  Monte-Carlo  analyses 

•  Port  code  to  Visual  Basic 

o  More  memory/better  memory  management 
o  Better  graphics/resolution 
o  Microsoft  Windows®-like  GUI 
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APPENDIX  B 

FORMATS  FOR  SCENARIO  FILES 


Scenario  file  records  consist  of  ASCII  character  strings  containing  variable-length  fields  delimited 
by  commas.  All  records  are  terminated  by  ENTER  or  RETURN  keyboard  control  characters.  The 
records  are  described  below: 

Record  1  (1  field)  -  filename  of  composite  detection  log  file,  enclosed  in  double  quotes 

Record  2(1  field)  -  number  (/)  of  sensors  in  scenario 

Records  3  thru  i+2  -  sensor  definitions  (one  record  for  each  sensor): 

Field  1  -  filename  of  detection  log  file  for  sensor,  enclosed  in  double  quotes 
Field  2  -  prob.  of  false  alarm  deemed  acceptable  for  sensor  (expressed  as  a  %) 

Field  3  -  initial  latitude  of  sensor  (decimal  degrees;  positive  for  North  latitudes,  negative 
for  South  latitudes) 

Field  4  -  initial  longitude  of  sensor  (decimal  degrees;  positive  for  East  longitudes, 
negative  for  West  longitudes) 

Field  5  -  shipping  noise  level  offset  at  sensor  location  (between  ±10  dB  re  1  qPa; 

positive  for  heavy  shipping,  negative  for  light  shipping) 

Field  6  -  sea  state  at  sensor  location  (between  0  (calm  seas)  and  6  (high  seas)) 

Field  7  -  array  gain  for  sensor  (dB  re  1  qPa) 

Field  8  -  standard  deviation  for  distribution  of  FOB  error  (degrees) 

Field  9  -  number  (/)  of  following  pairs  of  fields  defining  sectors  of  maximum  detection 
range  coverage  for  sensor  (1  <  /  <  5) 

Fields  10  [,  12,  14,  ...,  10±2(/-1)]  -  compass  bearing  for  CCW  side  of  sector  (degrees 
CW  from  North) 

Fields  1 1  [,  13,  15,  . . .,  1 1±2(/-1)]  -  maximum  detection  range  of  sector  (nautical  miles) 

Field  k  =  10±2/  -  number  (m)  of  following  triplets  of  fields  defining  track  legs  for  mobile 
sensors  {m-0  for  fixed  sensors;  1  <  m  <  10  for  mobile  sensors) 

Fields  [A:±l ,  A:±4,  . . .,  A:±l±3(m-1)]  -  latitude  of  endpoint  of  track  leg  (decimal  degrees; 

positive  for  North  latitudes,  negative  for  South  latitudes).  Fatitude  of  beginning  of 
track  leg  coincides  with  that  of  previous  leg  endpoint  (or  initial  position  of  sensor 
for  first  leg) 

Fields  [A:±2,  A:±5,  . . .,  A:±2±3(m-1)]  -  longitude  of  endpoint  of  track  leg  (decimal  degrees; 
positive  for  East  longitudes,  negative  for  West  longitudes).  Fongitude  of 
beginning  of  track  leg  coincides  with  that  of  previous  leg  endpoint  (or  initial 
position  of  sensor  for  first  leg) 

Fields  [A:±3,  A:±6,  . . .,  A:±3±3(m-1)]  -  speed  of  sensor  platform  in  track  leg  (knots) 

Record  /±3  (1  field)  -  number  (/)  of  targets  in  scenario 

Records  /±4  thru  /+/+3  -  target  definitions  (one  record  for  each  target): 

Field  1  -  target  start  time  (decimal  hours;  -1  =  non-active  target) 

Field  2  -  initial  latitude  of  target  (decimal  degrees;  positive  for  North  latitudes,  negative 
for  South  latitudes) 

Field  3  -  initial  longitude  of  target  (decimal  degrees;  positive  for  East  longitudes, 
negative  for  West  longitudes) 

Field  4  -  initial  speed  of  target  (knots) 

Field  5  -  target  speed  standard  deviation  (knots) 
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Field  6  -  maximum  speed  of  target  (knots) 

Field  7  -  initial  heading  of  target  (degrees  CW  from  North) 

Field  8  -  target  heading  standard  deviation  (degrees) 

Field  9  -  target  classifieation,  enelosed  in  double  quotes  (“F”=friendly,  “H”=hostile, 
“N”=neutral,  “U”=unknown) 

Field  10  -  number  (n)  of  following  pairs  of  fields  defining  narrowband  components  of 
signal  emitted  from  target  ( 1  <  n  <  10) 

Fields  11  [,  13,  15,  ...,  ll+2(n-l)]  -  frequency  of  signal  component  (Hz) 

Fields  12  [,  14,  16,  ...,  12+2(n-l)]  -  source  level  of  signal  component  (dB  re  1  |uPa) 

The  following  example  shows  the  contents  of  a  typical  scenario  file  with  1 3  sensor  platforms  and 
15  targets.  The  fields  of  typical  sensor  and  target  records  are  illustrated  in  Figures  B-1  and  B-2, 
respectively. 
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detection  log  filename  (“APM12.TXT”) 
r  sensor  probability  of  false  alarm  (2%) 

r  initial  sensor  platform  latitude  (35°N) 

r  initial  sensor  platform  longitude  (125°E) 

r  shipping  noise  level  offset  at  sensor  (0  dB  re  IpPa) 
r  sea  state  at  sensor  (l=light  breeze) 
r  sensor  array  gain  (12  dB  re  IpPa) 

r  standard  deviation  for  LOB  distribution  error  (1°) 
r  number  (/)of  detection  range  sectors  (1  360°  sector) 
r  sector  1  bearing  of  CCW  side  of  sector  (000°=North) 
r  sector  1  maximum  detection  range  (50  n.mi.) 
r  number  (m)  of  waypoint  track  legs  (2) 
r  leg  1  endpoint  latitude  (31.5°N) 

r  leg  1  endpoint  longitude  (125°E) 

r  leg  1  speed  (5  kts) 

I  r  leg  2  endpoint  latitude  (35°N) 

I  I  r  leg  2  endpt.  Ion.  (125°E) 
III  r  leg  2  speed  (5  kts) 

“APM12.TXT”,  2,  35.0,  125.0,  0,  1,  12,  1,  1,  000,  50,  2,  31.5,  125.0,  5,  35.0,  125.0,  5 


1  23  456789  (10  11)12  (13  14  15)(16  17  18)  <^Field 

Figure  B-1.  Typical  sensor  record  specification  (with  a  two-leg  “picket  line”  platform  waypoint  track). 

target  start  time  (6  hours  after  start  of  simulation) 
r  initial  target  latitude  (3 1  °30'N) 

r  initial  target  longitude  (121°30'E) 
r  initial  target  speed  (10  knots) 

r  standard  deviation  for  target  speed  distribution  (2  knots) 
r  maximum  target  speed  (20  knots) 
r  initial  target  heading  (090°) 

r  standard  deviation  for  target  heading  distribution  (5°) 
r  target  classification  (“U”=unknown) 

r  number  (n)  of  NB  signal  components  in  acoustic  signature  (2) 
r  T*  component  frequency  (100  Hz) 

I  r  1*’  component  source  level  (150  dB  re  1  pPa) 

I  I  r  2"“*  component  frequency  (120  Hz) 

I  I  I  r  2"^  component  source  level  (145  dB) 

6,  31.5,  121.5,  10,  2,  20,  090,  5,  “U”,  2,  100,  150,  120,  145 


1  2  3  4  5  6  7  8  9  10  (11  12)  (13  U)  ■(^Field 

Figure  B-2.  Typical  target  record  specification  (with  two  narrowband  signal  components). 
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APPENDIX  C 

FORMATS  FOR  DETECTION  LOG  FILES 


The  names  of  detection  log  output  files  are  specified  as  part  of  the  scenario  files  (Appendix  B). 
Detection  log  file  records  consist  of  ASCII  character  strings  containing  variable-length  fields 
delimited  by  commas.  Each  record  contains  detection  information  for  a  single  detection  or  false 
alarm.  All  records  contain  the  same  text  fields.  A  detection  record  can  contain  up  to  10  frequency 
component  fields;  if  fewer  than  10  frequency  components  were  detected,  the  remainder  of  the 
10  frequency  fields  are  blank  (null).  The  final  three  fields  of  each  record  contain  ground  truth 
information  appended  for  verification  purposes.  All  records  are  terminated  with  a  semi-colon  (;). 

The  field  descriptions  are  as  follows: 

Field  1  -  sensor  identifier 

Field  2  -  time  of  alert/false  alarm  (elapsed  time  in  decimal  hours  from  beginning  of 
simulation)  Note:  alert  time  includes  any  signal  propagation  time  to  sensor 

Field  3  -  latitude  of  sensor  (decimal  degrees;  positive  for  North  latitudes,  negative  for  South 
latitudes) 

Field  4  -  longitude  of  sensor  (decimal  degrees;  positive  for  East  longitudes,  negative  for 
West  longitudes) 

Field  5  -  line-of-bearing  to  target  (degrees  CW  from  North)  Note:  this  FOB  is  not  ground 
truth,  but  a  “fuzzified”  approximation  derived  from  an  error  distribution  about  the 
actual  FOB 

Fields  6-15  -  signal  frequency  components  (Hz)  Note:  these  frequencies  are  those  of  detected 
signal  components  only,  and  are  Doppler  shifted  to  account  for  any 
target/sensor  platform  relative  motion 

Field  16  -  maximum  sensor  detection  range  (nautical  miles)  in  the  direction  of  the  target. 

Note:  this  range  is  determined  from  the  sensor  coverage  specified  in  the  scenario 
file 

Field  17  -  ground  truth  latitude  of  target  (decimal  degrees;  positive  for  North  latitudes, 
negative  for  South  latitudes)  Note:  field  is  empty  if  alert  is  a  false  alarm 

Field  18  -  ground  truth  longitude  of  target  (decimal  degrees;  positive  for  East  longitudes, 
negative  for  West  longitudes)  Note:  field  is  empty  if  alert  is  a  false  alarm 

Field  19  -  classification  of  target.  Note:  field  contains  “FA”  if  alert  is  a  false  alarm 

The  following  example  shows  the  partial  contents  of  a  typical  composite  detection  log  file.  The 
fields  of  a  typical  detection  log  record  are  illustrated  in  Figure  C-1. 


APF09,4.03,30.00,130.00,69.3,60.1,120.3,180.4,,,,,,,,100,30.51,131.60,U; 
APFIO, 4 .02, 27 .00, 131 .00, 207 .2, 119. 9, ,,,,,,,,,150,26.33,130.66,0; 

APFIO, 4 .02, 27 .00, 131 .00, 101 . 6, 295. 9, ,,,,,,,,,150,,,FA; 

APFO 9, 4 .53, 30 .00, 130 .00, 70 .1,60.2,120.4,180.6,,,,,,,,100,30.46,131.56,U; 
APFIO, 4 .52, 27 .00, 131 .00, 211 .2, 119. 9, ,,,,,,,,,150,26.36,130.56,0; 

APM12, 4 .52, 34 .63,125.00,308.0,60.1,120.3,300.6,,,,,,,,50,35.10,124.21,H; 
APFO 9, 5.03, 30 .00, 130 .00, 72 .7, 60 .2, 120 .4, 180 .6,,,,,,,,100,30.37,131.50,0; 
APFIO, 5.02, 27 .00, 131 .00, 217 .2, 119. 9, ,,,,,,,,,150,26.37,130.49,0; 

APM12, 5.02, 34 .58, 125.00, 300 .5, ,120.3,300.9,,,,,,,,50,34.98,124.21,H; 

APFO 6, 5.52, 27 .00, 127 .00, 270 .5, 200 .4,  ,,,,,,,,,  100,,,FA; 

APFO 9, 5.53, 30 .00, 130 .00, 77 .4, 60.2,120.5,180.7,,,,,,,,100,30.27,131.44,O; 
APFIO, 5.52, 27 .00, 131 .00, 219. 8, 119. 8, ,,,,,,,,,150,26.40,130.41,0; 

APFIO, 5.53, 27 .00, 131 .00, 101 . 6, 261 .4, ,,,,,,,,,150,,,FA; 

APM12, 5.51, 34 .54, 125.00, 295.4, 60 .2, 120 .3, 300 . 8 ,,,,,,,, 50 ,34.84,124.24,0; 
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Figure  C-1.  Typical  detection  log  record  (with  one  detected  frequency  component). 
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APPENDIX  D 

OPERATING  INSTRUCTIONS  FOR  KMDT  SIMULATION  (VERSION  6) 


Introduction.  The  purpose  of  the  KMDT  simulation  module  is  to  generate  contact  information 
in  the  form  of  lines  of  bearing  (LOBs)  from  passive  sensor  systems  to  potential  targets  distributed 
in  some  theater  of  operations.  Sensor  systems  can  be  geographically  fixed  or  mobile,  as  for  example, 
a  moored  or  towed  acoustic  array  of  hydrophones.  The  targets  (with  pre-designated  signal  signatures) 
are  propagated  through  the  theater  using  a  quasi-random  motion  model.  At  every  time-step  during  the 
simulation  evolution,  a  determination  is  made  of  those  targets  detected  by  each  sensor  system  using 
a  range-dependent  probability  of  detection  computed  for  each  target-sensor  pair.  False  alarms  are 
also  generated,  and  along  with  detection  alerts,  are  entered  into  appropriate  “detection  log”  files 
for  access  by  external  software  agents.  The  attributes  and  initial  conditions  of  the  targets  and  sensors 
for  a  particular  scenario  are  specified  through  a  “scenario”  file.  See  Appendices  B  and  C  for  more 
information  on  the  contents  of  these  files.  Instructions  for  running  the  simulation  are  presented  as 
follows: 


Starting  the  simulation.  Before  starting  the  simulation,  make  sure  all  necessary  files  are  in  the 
same  folder  as  the  program  file,  KMDT6.EXE.  The  required  files  are  as  follows: 


KMDT6.EXE 

BRUN45.EXE 

CIE3.PNT 

MAPFONT.DAT 

TOPODATA.DAT 


-the  simulation  executable  program  file 
-a  required  run-time  module 
-coastline  coordinates  database  file 
-map  font  database  file 
-topographic  elevations  database  file 


Any  scenario  file(s)  to  be  run 


Output  detection  log  files  generated  during  the  simulation  will  be  created  in  the  same  folder.  These 
include  a  composite  log  of  detection  alerts  from  all  sensors  and  individual  logs  of  detection  alerts  for 
each  sensor.  Detection  log  files  are  assigned  names  via  the  scenario  file. 


To  start  the  simulation,  do  either  of  the  following: 

a.  Open  the  folder  containing  the  KMDT  simulation  files  and  double-click  on  the  file 
KMDT6.EXE.  This  method  will  then  prompt  for  the  name  of  a  scenario  file  that  must  be  entered 
manually.  Remember  to  include  any  filename  extension  when  entering  the  scenario  filename. 

b.  Double-click  on  the  desktop  icon  “Shortcut  to  KMDT6.EXE”,  if  present.  This  method  does  not 
require  typing  the  name  of  a  scenario  file,  but  only  one  pre-designated  scenario  file,  specified 
in  the  program  command  line  for  the  shortcut,  may  be  run.  The  name  of  the  pre-designated 
scenario  file  may  be  changed  by  right  clicking  on  the  icon,  opening  the  Properties  dialog  box, 
selecting  the  Program  tab,  and  editing  the  entry  in  the  window  next  to  “Cmd  line”  by  replacing 
the  scenario  file  name  following  the  program  name  KMDT6.EXE  at  the  end  of  the  entry. 

Running  the  simulation.  After  program  invocation,  a  geographic  map  of  the  theater  of  operations 
will  appear  with  a  mouse-activated  “arrow”  cursor.  Subsequent  interaction  with  the  simulation  may 
be  performed  either  by  using  the  mouse  or  the  keyboard.  At  the  top  of  the  screen  is  an  information/ 
command  line  illustrated  as  follows: 


TIME  =  0.00  hr  (A) dvance  time  (M) enu 

The  “TIME  =”  field  shows  the  elapsed  time  of  the  simulation  (in  decimal  hours),  and  is  incremented 
at  each  time-step  of  the  simulation.  The  time  may  be  incremented  in  discrete  time  steps  by  clicking 
the  left  mouse  button  while  the  arrow  cursor  is  over  the  “  (A)  dvance  time”  field,  or  by 
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depressing  and  releasing  the  “A”  key  on  the  keyboard.  After  release  of  the  left  mouse  button  or  “A” 
key  the  simulation  is  paused.  Alternately,  the  simulation  may  be  mn  continuously  by  holding  down 
the  left  mouse  button  or  “A”  key.  Note  that  when  a  target  detection  or  false  alarm  is  declared  after  a 
time  step,  a  detection  alert  window  appears  along  with  LOBs  from  any  sensors  detecting  the  target. 
For  discrete  updating,  clicking  anywhere  on  the  screen  or  pressing  any  keyboard  key  will  clear  the 
alert  window  and  associated  LOBs;  for  continuous  updating,  the  alert  window  and  associated  LOBs 
will  momentarily  flash  and  the  simulation  will  continue.  While  the  simulation  is  paused  between 
discrete  updates,  the  arrow  cursor  may  be  moved  over  the  +  symbol  denoting  the  location  of  a  sensor 
to  display  its  identification  tag  and  maximum  detection  range  coverage. 

Clicking  on  the  “  ( M )  enu”  field  (or  depressing  the  “M”  key)  will  open  a  menu  window,  as  illustrated 
below: 


-  MENU  - 

modify  (T) ime  step 
(A) dvance  time 
show  (D) etection  log 
show  (S)ensor  coverage 
show  map  (C)ursor 
(R) estart  simulation 
(Q)uit  simulation 


The  menu  options  are  activated  by  left-clicking  the  mouse  while  the  arrow  cursor  is  over  the 
desired  option  field  (or  alternately  by  depressing  the  keyboard  key  indicated  in  parentheses). 

The  menu  options  are  described  as  follows: 

modify  (T)  ime  step  Activating  this  option  displays  a  window  prompting  the  entry  of 
a  new  time-step  interval.  Enter  a  numeric  value  in  decimal  hours  (e.g.,  12  min  would  be  entered  as 
0.2  hours)  and  press  ENTER  on  the  keyboard.  Subsequent  time-steps  in  the  simulation  will  then  occur 
using  the  new  time  interval.  The  default  time  interval  is  0.5  hours  (30  min). 

(A)  dvance  time  Activating  this  option  advances  the  simulation  one  time-step  as  described 
earlier. 

show  (D)  etection  log  Activating  this  option  displays  a  window  containing  information 
about  the  10  most  recent  detection  alerts.  Clicking  anywhere  or  pressing  any  keyboard  key  will 
dismiss  the  window. 

show  (S)ensor  coverage  Activating  this  option  displays  the  area  of  coverage  of  each 
sensor  out  to  its  maximum  detection  range  (the  azimuth-dependent  detection  range  for  each  sensor 
is  specified  in  the  scenario  file).  Clicking  anywhere  or  pressing  any  keyboard  key  will  clear  the 
coverage  display. 

show  map  (C)ursor  Activating  this  option  will  display  a  “crosshair”  map  cursor  on  the 
screen,  along  with  additional  geographic  information.  At  the  top  right  of  the  screen,  an 
“ELEVATION  =”  field  will  appear  for  displaying  the  land  height  above  sea-level  (+  meters)  or  sea 
depth  below  sea-level  (-  meters)  of  the  cursor  position.  At  the  bottom  of  the  screen,  “EAT  =”  and 
“EON  =”  fields  will  appear  for  displaying  the  latitude  and  longitude  (in  decimal  degrees)  of  the 
cursor  position,  along  with  “RANGE  =”  and  “AZIMUTH  =”  fields  for  a  geodesic  (i.e.,  great  circle) 
range  (in  nautical  miles)  and  compass  bearing  (in  degrees  clockwise  from  North)  between  two 
positions  on  the  map.  Values  for  these  latter  two  fields  appear  only  when  the  mouse  is  dragged  while 
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depressing  the  left  mouse  button  to  move  the  cursor  from  a  “departure”  to  a  “destination”  location; 
a  corresponding  great  circle  line  from  departure  to  destination  is  also  plotted.  This  line  can  be  erased 
by  clicking  the  right  mouse  button,  but  only  if,  subsequent  to  drawing  the  line,  the  right  mouse  button 
is  clicked  before  any  other  mouse  button  or  keyboard  key.  Note  that  the  displayed  azimuth  is  the 
initial  bearing  from  departure  to  destination  at  the  departure  location,  as  this  bearing  will  vary  along 
the  geodesic.  While  utilizing  the  map  cursor  mode,  the  left  and  right  mouse  buttons  function  as 
follows:  Clicking  the  left  mouse  button  enables  discrete  updating  of  the  geographic  data  at  the 
current  position  of  the  cursor;  subsequent  updating  occurs  only  during  subsequent  mouse  clicks. 
Clicking  the  right  mouse  button  enables  continuous  updating  of  geographic  data  as  the  cursor  is 
moved  without  subsequent  mouse  clicks.  To  exit  the  map  cursor  mode  press  any  keyboard  key  while 
the  updating  is  continuous,  or  if  updating  is  discrete,  press  any  key  followed  by  a  mouse  click.  The 
cursor  will  then  revert  to  an  arrow  cursor. 

(R)  estart  simulation  Activating  this  option  will  restart  the  simulation  using  the  same 
scenario  file.  Previous  target  tracks  are  cleared  and  targets  and  sensors  parameters  are  reset  to  their 
initial  values.  All  detection  log  files  will  be  cleared  and  reinitialized. 

(Q)  uit  simulation  Activating  this  option  will  terminate  the  simulation  and  return  control  to 
the  computer  operating  system.  All  detection  log  files  will  be  saved  with  their  current  contents  from 
the  most  recent  simulation  run. 

Errors.  Errors  occur  very  rarely,  usually  when  some  mathematical  argument  is  out  of  range  or 
results  in  an  infinite  or  undefined  value.  When  such  an  error  is  detected,  a  warning  window  appears 
in  the  middle  of  the  screen  with  three  choices  to  proceed:  “  (A)  bort ,  (H)  alt ,  or 

(C)  ontinue”.  The  appropriate  choice  depends  on  the  error  or  warning  encountered,  and 
is  activated  by  depressing  the  keyboard  key  indicated  in  parentheses  (note:  clicking  the  mouse 
on  the  appropriate  field  will  not  activate  the  choice).  Selecting  “  (A)  bort”  will  terminate  the 
simulation,  returning  control  to  the  computer  operating  system.  In  many  cases,  however,  selecting 
“(C)  ontinue”  will  allow  the  simulation  to  continue  by  “stepping  over”  the  error.  (“  (H)  alt” 
is  an  option  primarily  intended  for  use  during  program  development.) 

Using  the  mouse.  The  simulation  is  sensitive  to  the  length  of  time  a  mouse  button  is  pressed.  That 
is,  if  the  mouse  button  is  not  released  fast  enough,  the  looping  control  in  the  simulation  may  advance 
beyond  a  single  time-step,  and  simulation  displays,  such  as  detection  alerts,  may  appear  to  flash  on 
and  off,  rather  than  remain  visible  on  the  screen.  If  such  behavior  is  observed,  fry  to  click  the  mouse 
faster  (that  is,  unless  the  mouse  hut-ton  is  being  held  down  deliberately  to  effect  a  continuous 
mnning  of  the  simulation). 
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APPENDIX  E 
DETECTION  THEORY 


Let  be  a  signal  originating  from  some  source  in  a  background  of  Zero  Mean  Gaussian  (ZMG) 
noise  n.  If  x  represents  the  signal  arriving  at  some  receiver,  then  either  of  the  following  hypotheses 
may  hold: 

Ho :  V  =  n,  if  the  source  signal  is  absent. 

Hi  :  x  =  s  +  n,  if  the  source  signal  is  present. 

These  are  called  the  null  and  alternative  hypotheses,  respectively.  If  the  received  signal  x  exhibits 
a  Normal  (Gaussian)  distribution  lK{/a,  cr^),  where  fj.  and  cr^  are  the  mean  and  variance  of  the 
distribution,  then  under  hypothesis  Ho,  x  ~  iV(0,  cr^ )  and  under  hypothesis  Hi,  x  ~  W(  s,  <7^^^ ), 
where  s  is  the  mean  signal  level.  The  associated  probability  density  functions  for  x  under  Ho  and  Hi 
are,  respectively, 

=  exp[-xV(2o-„")] 

and 

Pi  (x)  =  (27ral„  exp[-  {x-sf  j  (2al„ )] 

=  exp[-(x-T)V(2^^cr„^)], 

where  / cr^  .  The  parameter  k  implicitly  incorporates  the  effect  of  a  fluctuating  source 

signal  in  the  probability  density  function J9i(x):  For  a  fluctuating  signal,  >  cr^  so  that  l^  >  \, 
while  for  a  steady  signal,  =  cr^  so  that  k?'  =  1.*  In  this  latter  case,  the  effect  of  adding  a  constant 

signal  to  the  ZMG  noise  effectively  shifts  the  noise  density  function  in  the  +x-direction  by  the 
amount  s  ,  as  illustrated  in  Figure  E-1. 


Figure  E-1.  Overlapping  Gaussian  distributions. 


Because  the  use  of  the  parameter  k  eliminates  the  explicit  dependence  of p\{x)  on  ,  only  explicitly  remains  in  the  expressions  for  poix) 

and  pi(x).  Thus,  for  notational  simplicity,  the  subscript  n  will  hereafter  be  dropped  with  the  understanding  that  cr^  refers  to  the  variance  of  the 
noise  distribution. 
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In  detection  theory,  the  objective  is  to  choose  between  Ho  and  Hi,  given  some  sample  of  the 
received  signal  x,  called  the  test  statistic.  In  doing  so,  two  types  of  errors  may  occur.  A  Type  I  error 
occurs  if  Ho  is  selected  when  in  fact  a  source  signal  is  present;  this  error  occurs  with  the  following 
probability: 

=  P(x  e  I  Hi )  =  Pi  (x)  dx , 

called  the  probability  of false  dismissal.  Note  that  the  probability  of  detection  of  the  source  signal 
is  =  1  -  Pfd.  A  Type  II  error  occurs  if  Hi  is  selected  when  in  fact  no  source  signal  is  present;  this 
error  occurs  with  probability 

Pfa  =  Pi^  e  Ri  I  Ho)  =  \"pq{x)  dx  , 

called  the  probability  of  false  alarm.  Note  that  Pfa  is  the  shaded  area  in  Figure  E-1.  In  either  case, 
the  limit  of  integration  y  represents  a  threshold  value  against  which  x  is  compared  in  order  to  decide 
between  Ho  and  Hi. 

The  decision  between  Ho  and  Hi  is  usually  made  by  defining  a  likelihood  ratio,  T(x)  =  p\{x)l pfx). 
Note  that  for  the  probability  density  functions  above, 

A.(x)  =  \Qx^[{k^x^  -x^  +lsx-s^)l{2k^(j^)'\. 

Then  for  threshold  y,  the  test  becomes 

Accept  Hi  if  A.(x)  >  A(y). 

Reject  Hi  if  Mx)  <  /1(f). 

The  likelihood  test  depends  on  finding  an  appropriate  value  for  the  threshold  y.  Unfortunately,  the 
source  signal  s  is  usually  unknown,  so  the  probability  density  function pfx)  cannot  be  specified. 

In  this  case,  the  usual  approach  is  to  apply  the  Neyman-Pearson  criteria:  Maximize  Pd  subject 
to  some  acceptable  Pfa-  For  the  noise  distribution  above,  the  probability  of  false  alarm  may  be 

expressed  in  terms  of  the  Error  function,  erf(x)  =  ^J^exp(-y  )dy  follows: 

Pfa=^  Pq{x)  dx  =  {27i<7^)  exp[-x^/(2cr^)](ix 

=  |-lerf(r)  =  l[l-erf(r)], 

where  the  substitution  y  =  x/ (V2  cr)  has  been  made  and  where  F  =  yl (V2  cr) .  That  is,  erf(/) 

+  2Pfa-\=Q.  For  a  specified  Pfa,  this  last  equation  can  be  solved  numerically  for  F  (and 
hence  y  =  F<j42  ,  provided  that  the  variance  cr^  of  the  noise  distribution  is  known  or  can 
be  estimated). 
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With  the  value  of  /"thus  determined,  the  probability  of  detection  for  the  signal  plus  noise 
distribution  is 


Pd  -  /i  W  dx  =  exp[-(x-5)^/(2A:^cr^)]/x 

^1-erfl 


=  |-|erf| 


r-D 


_  1 

2 


r~D 


where  the  substitution  y  =  (x-  s)j{-yl2  ka)  has  been  made  and  where  D  =  s/{-yj2  a) .  Since  D 
is  a  function  of  the  unknown  source  signal  mean  5  (as  well  as  the  noise  variance  cr^ ),  Pd  as  yet 
cannot  be  determined.  However,  the  quantity  d  =  5^/cr^  =  2D^ ,  called  the  detection  index, 
is  a  measure  of  the  signal-to-noise  ratio  (SNR).  Extensive  work  has  been  performed  in  acoustics  and 
electromagnetics  to  develop  equations  defining  the  SNR  in  various  environments. 

E.1  DETECTION  OF  ACOUSTIC  SIGNALS 

For  acoustic  environments,  the  appropriate  SNR  equations  are  the  passive  and  active  SONAR 
equations.  For  passive  SONAR,  the  source  signal  originates  from  the  target,  whereas  for  active 
SONAR,  the  source  signal  originates  from  a  transducer  and  reflects  from  the  target.  These  equations 
(in  units  of  decibels  are 

DT  =  SF  -  TL  +  AG  -  AN 
and 

DT  =  SF  -2TF  +  TS  +  AG  -  AN, 
respectively,  where 

DT  =  Detection  Threshold,  the  SNR  necessary  to  achieve  a  desired  level  of  performance 
(DT  is  also  called  the  Recognition  Differential,  RD) 

SF  =  Source  Level,  the  ratio  of  the  acoustic  intensity  (proportional  to  the  squared 
pressure)  of  the  source  to  that  of  a  plane  wave  of  rms  pressure  Pq  =  \  //Pa  at  a 
reference  distance  ro  =  1  m  from  the  source. 

TF  =  Transmission  Loss,  the  ratio  of  the  acoustic  intensity  at  a  distance  ro  =  1  m  from  the 
source  to  that  at  a  distance  r  from  the  source. 

AG  =  Array  Gain,  the  ratio  of  the  SNR  of  an  array  of  coherently  summed  receiver 
elements  to  that  of  a  single  element. 

AN  =  Ambient  Noise,  the  spectrum  level  (power)  of  all  incoherent  sources  of  noise  in  a 
1-Hz  band  at  the  receiver 

TS  =  Target  Strength,  the  ratio  of  the  acoustic  intensity  reflected  from  a  target  at  a 

distance  ro  =  1  m  from  the  target  to  that  from  a  source  at  distance  r  from  the  target. 

In  the  active  SONAR  equation,  the  Reverberation  Level,  RL,  replaces  the  terms  (AN-AG)  for 
environments  where  the  reverberation  level  exceeds  that  of  the  AN.  Note  that  there  are  various 
representations  for  the  terms  of  the  SONAR  equation  with  different  levels  of  fidelity.  For 
example,  in  a  homogeneous  seawater  environment,  TF  may  be  modeled  by  simple  spreading  loss 
and  absorption.  However,  boundaries  and  spatial  and  temporal  variability  of  the  sound  field  can 
cause  refraction  and  other  effects  requiring  sophisticated  computer  models  and  environmental 
databases  for  evaluation. 
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Thus,  for  a  given  SL,  TS,  AG,  and  AN  appropriate  for  the  source,  target,  receiver,  and  ambient 
environment,  and  assuming  some  model  for  the  TL,  the  passive  or  active  SONAR  equation  may  be 
evaluated  for  the  DT.  Since  DT  =10  log  d,  the  detection  index  d  can  be  found  from 

d=  antilog[DT/10] 

=  antilog[(SL  -  TL  +  AG  -  AN)/10],  for  passive  acoustic  detection; 

=  antilog[(SL  -  2TL  +  TS  +  AG  -  AN)/10],  for  active  acoustic  detection. 

Then  D  =  -Jd/l ,  and  the  probability  of  detection  may  be  estimated  from 


P  -  T 

-  2 


1 

1-erf  — 


V  k 


Note  that  since  the  TL  is  range-dependent,  so  is  the  Pd.  Also  note  that  the  variance  of  the  noise 
distribution  cr^ ,  is  implicitly  incorporated  within  the  terms  /"and  D,  and  therefore  does  not  need 
to  be  known  or  estimated. 
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APPENDIX  F 

KMDT  DEMONSTRATION  CONCEPT 


The  KMDT  demonstration  involves  the  use  of  two  computers  connected  via  a  local-area  network 
(LAN).  One  computer  runs  a  simulation  based  on  a  scenario  involving  multiple  targets  and  sensor 
platforms,  and  a  contact  generator  that  provides  line-of-bearing  (LOB)  alerts  on  detected  targets 
(including  false  alarms).  Detection  alerts  are  posted  to  databases  residing  in  the  simulation  computer 
that  may  be  accessed  by  the  second  computer  via  the  LAN.  The  second  computer  acts  as  a  command 
center,  where  requests  for  information  originate,  software  agents  are  tasked  to  gather  appropriate 
information  from  the  network  (i.e.,  from  the  detection  databases),  and  subsequent  data  fusion  takes 
place.  The  detection  databases  will  serve  the  KMDT  demonstration  as  “Web  portals”  providing  Web 
services  to  the  network.  The  demonstration  functional  configuration  is  illustrated  in  Figure  F-l. 


SIMULATION 


LAN 


COMMAND  &  CONTROL 


Figure  F-1.  Demonstration  functional  configuration. 

When  a  request  for  information  is  initiated,  a  software  agent  is  tasked  to  acquire  records  from  the 
detection  databases  via  the  LAN.  The  software  agent  is  basically  a  program  on  the  command  and 
control  computer  that  establishes  connectivity  with  the  simulation  computer,  reads  records  from  the 
detection  databases,  and  decides  whether  or  not  the  records  contain  information  that  might  be 
valuable  in  satisfying  the  request. 

To  accomplish  this  task,  the  software  agent  must  have,  among  other  things,  access  to  additional 
ontology  and  knowledge  databases  (such  as  sensor  and  target  information  libraries,  taxonomies,  etc., 
residing  in  the  command  center  computer  or,  perhaps,  on  a  third  computer)  that  contain  information 
on  various  sensor  parameters,  classification  signatures,  data  relationships,  etc.  The  software  agent 
must  also  have  algorithms  to  decide  if  acquired  information  is  appropriate.  In  essence,  these 
algorithms,  along  with  the  relationships  defined  in  the  ontology  and  knowledge  databases,  provide 
the  “intelligence”  of  the  agent. 
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